Re: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt]

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Thu, 01 November 2018 10:49 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA1130934; Thu, 1 Nov 2018 03:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 ouq87ys4gqBp; Thu, 1 Nov 2018 03:49:02 -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 15DE3127B92; Thu, 1 Nov 2018 03:49:01 -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 wA1Amu91017623; Thu, 1 Nov 2018 11:48:56 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6AF361D53C1; Thu, 1 Nov 2018 11:48:55 +0100 (CET)
Received: from 79.158.50.20 by webmail.entel.upc.edu with HTTP; Thu, 1 Nov 2018 11:48:56 +0100
Message-ID: <c4a13e531649e6f80fd25fa4df6047fd.squirrel@webmail.entel.upc.edu>
In-Reply-To: <CAO249yf9bQbCY0iM4gkJbXhO-m=z2U1Vmp39ThkHjk-5xXMoMQ@mail.gmail.com>
References: <26ed385e2f00a41e717a9d4b4043f9b9.squirrel@webmail.entel.upc.edu> <CAO249yf9bQbCY0iM4gkJbXhO-m=z2U1Vmp39ThkHjk-5xXMoMQ@mail.gmail.com>
Date: Thu, 01 Nov 2018 11:48:56 +0100
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, lwip@ietf.org, jon.crowcroft@cl.cam.ac.uk
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.99.2 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]); Thu, 01 Nov 2018 11:48:57 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/kahZnj0dL3VpC1jvovpivF2BGQs>
Subject: Re: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt]
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2018 10:49:05 -0000

Hello Yoshi,

Sorry for the late reply, and thanks a lot for taking the time for your
review and for providing comments.

Please find below my inline responses:

> Hello,
>
> I've read the draft and I think the draft looks fine and mostly ready.
> I have some comments below..
>
> 1: Section 4.2.4:
>   "In that case, RTO algorithm tuning may be considered, although
> careful assessment of possible drawbacks is recommended"
>
> -> It might be better if we refer draft-ietf-tcpm-rto-consider here
> although it is not very certain the draft will be published at this
> moment? It seems to me the motivation of the doc fits the situation
> like this.

I agree. I guess we may cite draft-ietf-tcpm-rto-consider as an
informative reference for this section.

> 2: Section 4.3.1:
>    "These algorithms work efficiently for window size of at least 5 MSS"
>
> -> Just curious why this is 5? Is it because the use of delayed ack is
> presumed?
>      A receiver may have a chance to send an ack for segment 1 before
> segment 3 arrives.

Yes, the text was written under the assumption that delayed ACKs might be
in place. In the next revision we will explicitly indicate the assumption,
and update the related text as per your comment.

> 3: Section 5.3
>     CCN -> CNN?

Thanks for catching the typo!

>    "This overhead could be reduced by TCP Fast Open (TFO)"
>
> -> Yes, but the use of TLS is not mandatory in this draft. If an
> implementation utilizes TFO, we might want to mention about app level
> idempotency here.

Not sure I'm following you here. Could you please elaborate?

>    "TCP keep-alive messages are not very useful to..."
>
> -> We don't need to discuss reducing the interval of keep-alive here?

Currently, we have some text on this, although I agree it is a bit too
indirect. In the next revision, we will elaborate further.

Once again, thanks for your comments.

Cheers,

Carles


> Thanks,
> --
> Yoshi