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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sat, 03 November 2018 07:08 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 6866312D4EA; Sat, 3 Nov 2018 00:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 0WAFjS-uo6Hs; Sat, 3 Nov 2018 00:08:02 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB3E130E01; Sat, 3 Nov 2018 00:08:01 -0700 (PDT)
Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A4FAD27855D; Sat, 3 Nov 2018 16:07:59 +0900 (JST)
Received: by mail-it1-f176.google.com with SMTP id h13so6181086itl.1; Sat, 03 Nov 2018 00:07:59 -0700 (PDT)
X-Gm-Message-State: AGRZ1gJl2vIHXu9kewyXFKCyx/huYJYkDEwGRhm0pCtNPYlCXd9cWg2/ nMqWDgDxnG6iISD7ZxdSz+7Px1EOYC6XwFYudPA=
X-Google-Smtp-Source: AJdET5fKvEKZCAVTHgOiQm//L2P2YY9NB3ezjx0U86Qc1urH2jDNCh2v1PKqkSCdLWRIxytaq5hjrCQ5Ogs4IuPKqL4=
X-Received: by 2002:a24:36d2:: with SMTP id l201-v6mr100050itl.130.1541228878272; Sat, 03 Nov 2018 00:07:58 -0700 (PDT)
MIME-Version: 1.0
References: <26ed385e2f00a41e717a9d4b4043f9b9.squirrel@webmail.entel.upc.edu> <CAO249yf9bQbCY0iM4gkJbXhO-m=z2U1Vmp39ThkHjk-5xXMoMQ@mail.gmail.com> <6EC6417807D9754DA64F3087E2E2E03E2D14760C@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D14760C@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sat, 3 Nov 2018 00:07:47 -0700
X-Gmail-Original-Message-ID: <CAO249yd1uACsSsCWE3doN_tLfPA1Z26v-KkjtpXZ4HBcyMi5wQ@mail.gmail.com>
Message-ID: <CAO249yd1uACsSsCWE3doN_tLfPA1Z26v-KkjtpXZ4HBcyMi5wQ@mail.gmail.com>
To: Michael.Scharf@hs-esslingen.de
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, carlesgo@entel.upc.edu, lwip@ietf.org, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cea2400579bd4fdf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ZV59Ge28jv5X8A0v9DKFHqCHDC4>
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: Sat, 03 Nov 2018 07:08:06 -0000

Hi Caerles, Michael,

Thanks for the addressing the comments.

On Thu, Nov 1, 2018 at 7:47 AM Scharf, Michael <
Michael.Scharf@hs-esslingen.de> wrote:

> Chiming in...
>
> > 3: Section 5.3
> >     CCN -> CNN?
> >
> >    "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.
>
> We could add the following two sentences from RFC 7413 at the end of the
> paragraph:
>
>   "However, TFO deviates from the standard TCP semantics, since the data
> in the SYN
>    could be replayed to an application in some rare circumstances.
> Applications
>    should not use TFO unless they can tolerate this issue, e.g., by using
> Transport
>    Layer Security (TLS)."
>

Works for me.

>
> >    "TCP keep-alive messages are not very useful to..."
> >
> > -> We don't need to discuss reducing the interval of keep-alive here?
>
> We could add the following sentence (again adapted from RFC 7413):
>
>   "Sending TCP keep-alive probes more frequently risks draining power on
> mobile
>   devices [MQXMZ11]."
>
> I am not sure how much more guidance we could give on picking an interval.
>

I agree. I think we don't need to talk about specific interval.
I just thought it would be good to mention it as this is one possible way
although it might not be a good approach in some cases.

Thanks,
--
Yoshi