[6tisch] 6P Timeout in MSF

Tengfei Chang <tengfei.chang@gmail.com> Fri, 23 August 2019 12:49 UTC

Return-Path: <tengfei.chang@gmail.com>
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 C44BA1200DF for <6tisch@ietfa.amsl.com>; Fri, 23 Aug 2019 05:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ClkvXe7_CTb7 for <6tisch@ietfa.amsl.com>; Fri, 23 Aug 2019 05:49:11 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 2DC8112003E for <6tisch@ietf.org>; Fri, 23 Aug 2019 05:49:11 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id w26so6387637pfq.12 for <6tisch@ietf.org>; Fri, 23 Aug 2019 05:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LRV6jD74eIe42rqGB40NVmtCG7P0fUgc5mCDARpSoEE=; b=ZOGYLukS7H9NJ4Uw4ZIJKQSMXiiMIu27R9S8ho704B4Sei73NDHorUogjf8YGLUm5p Uc8N6cJNBlBofrRpe/db+3iYATVMxoMFLcBnEY8+AA/dNQT2tD8HXov4eGRdIepQjpfM 6gwi1eAT6Ry83vGIUT3yWSiTgQQWtrBaXZxHqS383TbHDrplr0J0+bSgW1o1qLesHxY0 lmT9ejDge6jipl2m+pvhfF4M8dBzp+EtzebKC9LY9xORTjSKA2QLx7tkoWQq27jf61Cm c9HfSiml9MoiWc7QQiZs8BOdnH5c24TruQMf3ydPs7WP+8NH7jS6YoAE3e9w12ESd64s Ea1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LRV6jD74eIe42rqGB40NVmtCG7P0fUgc5mCDARpSoEE=; b=kiYck6+3kykmNHReEg9e0JGvQDaInXs8np+rjHRVbkDm4cRxXziMLxYpIlbAXxGKXJ 4XJBY1f6IfCa/lcidUbgOXOk1Q+uFxCmmQCbAV2nYtrAdSNtaLV0+M11L7cB7zW7JHVx zwxT4RuxuvecMVb/m0Ja4oJtNRcB0a0laxocQzUkdkEOOkTLmhJe1zDiWH/XHmFyNhRm DcRub8tQYbYbKKnbZVOyWQEOmJIfM7ratra8FVTZzeu/1iK4lkck0+/ZthV0Wh2jmxwl LCpz0Bciwy9TndB0hJ3YwrrqF97NLrQMaSvwO81aua3gNp014X/+zvAOR1lhtS32L1d1 uOSQ==
X-Gm-Message-State: APjAAAWDwgznxU6u/H2l669nbRfqKwxjCkSgsbthpsUXxm+PH1ysrgqP EYioeGv6WH5EEJ75sKwIJ0cYnXjOLoXDvJwGIkIEOrfJSOI=
X-Google-Smtp-Source: APXvYqw/BIriMCDr4uVi3WKfMWK28wpDWwccFdJqnvDfOeGcKXvhyYF9f/w507cSMkoubavp4zSjcmDzlT65eItd7/E=
X-Received: by 2002:a17:90a:858a:: with SMTP id m10mr5076009pjn.129.1566564550268; Fri, 23 Aug 2019 05:49:10 -0700 (PDT)
MIME-Version: 1.0
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Fri, 23 Aug 2019 14:48:57 +0200
Message-ID: <CAAdgstS1PD7w0=p4ZnCAqSi+DZM+XYXFO7MGGCR=pdRjki0HOQ@mail.gmail.com>
To: 6tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000895a6d0590c83bca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/irxCMe9AWzBxXKktGqVxMyr8vIo>
Subject: [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: Fri, 23 Aug 2019 12:49:13 -0000

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