Re: [6tisch] 6P Timeout in MSF

<toshio9.ito@toshiba.co.jp> Mon, 02 September 2019 01:16 UTC

Return-Path: <toshio9.ito@toshiba.co.jp>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9772F12022C for <6tisch@ietfa.amsl.com>; Sun, 1 Sep 2019 18:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vRSsCbHytRbs for <6tisch@ietfa.amsl.com>; Sun, 1 Sep 2019 18:16:30 -0700 (PDT)
Received: from mo-csw.securemx.jp (mo-csw1115.securemx.jp [210.130.202.157]) (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 7BCBB120232 for <6tisch@ietf.org>; Sun, 1 Sep 2019 18:16:30 -0700 (PDT)
Received: by mo-csw.securemx.jp (mx-mo-csw1115) id x821GQML026057; Mon, 2 Sep 2019 10:16:26 +0900
X-Iguazu-Qid: 2wHHJJGUDltPpu7aux
X-Iguazu-QSIG: v=2; s=0; t=1567386986; q=2wHHJJGUDltPpu7aux; m=rSL7GRUP1Q2Bcq+RcHwL5g4QJtqtEqFB2+eyDuykMgo=
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.securemx.jp (mx-mr1111) id x821GQ3X012510; Mon, 2 Sep 2019 10:16:26 +0900
Received: from enc02.toshiba.co.jp ([61.202.160.51]) by imx12.toshiba.co.jp with ESMTP id x821GPFt017634; Mon, 2 Sep 2019 10:16:25 +0900 (JST)
Received: from hop101.toshiba.co.jp ([133.199.85.107]) by enc02.toshiba.co.jp with ESMTP id x821GPPa002972; Mon, 2 Sep 2019 10:16:25 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YjpvD6P7kQP5sOnSjYdx7wiV+8folSgq+eOlovFrgdtteQbbnWOWTB44Gmvprmqg1pWgvqoXvV/8N9KN/EPyseZP95lwczFJEcTX+NBw6RUgua7P+N8d2Rw5PVfBig8CIrN+CiWlXrdB/+7P3aMUs+++IJsYAH4GeEi1lkVZ+dN2nl5dvXicbYxZTiRgjSFuvmQi6qITXJVr2mbqFjRyIulMpdxPd/hqxcTx6GJcBx7m8GSsFNo6lB2DXm0+HnMeBcLw0wYF28Vr6NnmwI6D3lR1HOn+8SGBAR+NZVnQ9BbWc4ZtL0NL/P/MoPJRO71H2NTaUiLyEtV7ag14KmeSmQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3cw8DOPEKOoARvteN3ltBrf1epyM3OVX9733u1eGfv8=; b=QuNxyTDfR9kDb6MhKQv/YYNSnZLhf18cokL9c4BGhdB/ITkWxLEQymy+UAC7s2iWDglw9F+wtp1V5B1VrOEdsr9zsiBVLiNzqm0ISQubnwj3yDob3z1XB4pUpeiM1hNLCim6YDacfUAEctN9ul8c5qoO3c/av9kwoghjPcUZxvrChTlOHQ5HaBcknKXRXeimVm8iDFjzoifCb0NvOQ9MDVAXECJgzkVvnVUYUxN/gAloBWdtWg8mO0h5y7cJsABaJtlWbdN0+iRrOm6VEu5UfYMIostrS8cmbAiIi9J5H6SFWg/cphPrZ8O/X1gKNK+gjcrFwLOVqRWV3BW8xML6Qg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=toshiba.co.jp; dmarc=pass action=none header.from=toshiba.co.jp; dkim=pass header.d=toshiba.co.jp; arc=none
From: toshio9.ito@toshiba.co.jp
To: tengfei.chang@gmail.com, 6tisch@ietf.org
Thread-Topic: [6tisch] 6P Timeout in MSF
Thread-Index: AQHVWbE41XDoxSFfdUGTKgUeTJ6P0KcXozaw
Date: Mon, 02 Sep 2019 01:15:18 +0000
X-TSB-HOP: ON
Message-ID: <TYAPR01MB2383E6E71A4B8C1B5A3E6F27E5BE0@TYAPR01MB2383.jpnprd01.prod.outlook.com>
References: <CAAdgstS1PD7w0=p4ZnCAqSi+DZM+XYXFO7MGGCR=pdRjki0HOQ@mail.gmail.com>
In-Reply-To: <CAAdgstS1PD7w0=p4ZnCAqSi+DZM+XYXFO7MGGCR=pdRjki0HOQ@mail.gmail.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
authentication-results: spf=none (sender IP is ) smtp.mailfrom=toshio9.ito@toshiba.co.jp;
x-originating-ip: [103.91.184.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 666208c8-e454-4d79-a96b-08d72f4304d0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:TYAPR01MB2496;
x-ms-traffictypediagnostic: TYAPR01MB2496:
x-microsoft-antispam-prvs: <TYAPR01MB2496BBE35C5C4FCB21C53826E5BE0@TYAPR01MB2496.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01480965DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(366004)(376002)(136003)(199004)(189003)(53754006)(102836004)(46636005)(26005)(9686003)(54896002)(66476007)(186003)(2906002)(14454004)(33656002)(66946007)(66446008)(64756008)(66556008)(76116006)(52536014)(5660300002)(6116002)(3846002)(7696005)(316002)(6306002)(76176011)(6506007)(53546011)(66066001)(478600001)(8676002)(81166006)(11346002)(446003)(81156014)(476003)(8936002)(110136005)(74316002)(486006)(7736002)(229853002)(99286004)(256004)(25786009)(14444005)(55016002)(71200400001)(71190400001)(53936002)(86362001)(6246003)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:TYAPR01MB2496; H:TYAPR01MB2383.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: toshiba.co.jp does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4FgZmi2mASthI6Yec8PiYvVMx4EFOIQiGGjMoQ6kbrAsNQy8p077ZIhfGA+Mv0I37ysjr/qFlCetB97uEMG+jZtL510JzqaKxm+gRdkfi3kQ20rzbnBTMXPeNWOLR3rvEVuJ1FX7M022ISFjczTm5RtvoGncNlb048mK7TxmlYxyXn93iqNwVCepbachnQ79UmoG6ClmrQxOHnqJ2nv0THVo1NYOlaxLSfgw5zRFcslBnkWwjACPsAEqBjkdQW4amcY/88QTh/ZsGfQePTKdMB1DvHPj4StwT+JEAoUX3C7J1EpddZJqWXnPz6rv74h6+7hDNtvd+l446+nGE25Ng3eXH10w65/S/wBN6lFulred0MsMlXxu08805XbpRklS2o2cjxYlZaYXq2u7Gj0unJnskvUDRkb9p9RkWnQyEkg=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_TYAPR01MB2383E6E71A4B8C1B5A3E6F27E5BE0TYAPR01MB2383jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 666208c8-e454-4d79-a96b-08d72f4304d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 01:15:18.5393 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: E7USUtF2BgmLm1CGTfnbsj/NAemJHbrA5gwvkUJz+HrqoKbsuF8k30H25xmJufr4Loyb1nx77MQRgAJgxt207TRSoYQdsCLRPDEqIYck4Jg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2496
MSSCP.TransferMailToMossAgent: 103
X-OriginatorOrg: toshiba.co.jp
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/OnCSAXcOAGQTTA4AvnPKEdE_q9g>
Subject: Re: [6tisch] 6P Timeout in MSF
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 01:16:39 -0000

Hi Tengfei,

I'm not sure if this is really a problem, but maybe we can start
with a small timeout and extend it exponentially every time we
observe 6P Timeout. In that case, the current definition of
TIMEOUT can be the upper bound of the timeout.


Best regards,
Toshio Ito


From: 6tisch <6tisch-bounces@ietf.org> On Behalf Of Tengfei Chang
Sent: Friday, August 23, 2019 9:49 PM
To: 6tisch <6tisch@ietf.org>
Subject: [6tisch] 6P Timeout in MSF

Hi All,

For the current version (06) of MSF,  we defined the 6P Timeout as the result of following equation:


6PTIMEOUT = ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH

   o  MAXBE is the maximum backoff exponent used

   o  MAXRETRIES is the maximum retransmission times

   o  SLOTFRAME_LENGTH represents the length of slotframe



What I believed is this is the right timeout value according the definition of RFC8480:



The value of the 6P

   Timeout should be greater than the longest possible time it takes to

   receive the 6P Response or Confirmation.



However, this value could be super large depending the value of MAXBE and SLOTFRAME_LENGTH.

For example, MAXBE = 5, MAXRETRIES=8 (to get a better reliability), SLOTFRAME_LENGTH=101.
for 10 ms slot duration, the 6P timeout is more than 4 minutes. This could cause large delay for 6P transaction, for example at network forming phase.



So my concerns on the 6P Timeout are

- do you think this is an issue or not

- if yes,  what's your suggestion?



Thanks!



Tengfei

--
Chang Tengfei,
Postdoctoral Research Engineer, Inria