Re: [6tisch] MSF adapts to traffic only for secured packets

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Thu, 05 December 2019 18:59 UTC

Return-Path: <yasuyuki.tanaka@inria.fr>
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 4A3FF12006B for <6tisch@ietfa.amsl.com>; Thu, 5 Dec 2019 10:59:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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 Hjbx4Ki-XXgg for <6tisch@ietfa.amsl.com>; Thu, 5 Dec 2019 10:59:23 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52D112002F for <6tisch@ietf.org>; Thu, 5 Dec 2019 10:59:22 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,282,1571695200"; d="scan'208";a="331509821"
Received: from poi92-3-88-190-144-98.fbxo.proxad.net (HELO [192.168.1.29]) ([88.190.144.98]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Dec 2019 19:59:20 +0100
Cc: yasuyuki.tanaka@inria.fr, 6tisch@ietf.org
To: Mališa Vučinić <malisa.vucinic@inria.fr>
References: <CAAdgstRGHyRKoMLBhRih8yHwDvf-DTp42ZTEBmBP57FSgt8MyA@mail.gmail.com> <00c074fd-2423-1620-a7d1-3a899bbd000e@inria.fr> <8D2F7CA6-31BC-4091-8358-F7C86A0A5B37@inria.fr> <ddfdfcad-d3ee-99b6-eb60-19b3d33acca7@inria.fr> <4CC17511-E927-43B5-A744-E51F048F6033@inria.fr>
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Message-ID: <e810af7a-4863-967b-e813-e1f788253144@inria.fr>
Date: Thu, 05 Dec 2019 19:59:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <4CC17511-E927-43B5-A744-E51F048F6033@inria.fr>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/yLaa6EdPH97cdQIqu1JRVjrxGN8>
Subject: Re: [6tisch] MSF adapts to traffic only for secured packets
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: Thu, 05 Dec 2019 18:59:25 -0000

Hi Malisa.

Thanks to your explanation, I get the point.

> how could we ensure that the “acceptable” amount of unauthenticated traffic that actually gets forwarded does not trigger cell allocation?

It'd be fine to trigger cell allocations by *acceptable* amount of 
unauthenticated traffic if necessary. Otherwise, important packets, 
authenticated traffic for applications, could be dropped because of no 
room in the TX queue filled with unauthenticated packets.

Or, the intermediate route should drop more "unauthenticated" traffic if 
you don't want to trigger. But, even doing this, we cannot ensure the 
first relayed join request since the last hour or year does not trigger 
a cell allocation.

> The cells used to transport the join traffic will be marked as used by MSF, and depending on the amount of regular traffic as well as the join rate limit, this may cause the cell allocation threshold to be surpassed. Right?

Yes, it causes another cell allocation.

Any L2 component including MSF doesn't case about information in the MAC 
frame payload field, although MSF (a 6TisCH scheduling function) is not 
on the path of outgoing packets in the protocol stack:

 
https://tools.ietf.org/html/draft-ietf-6tisch-architecture-28#section-3.7
       +--------+--------+
       | Applis |  CoJP  |
       +--------+--------+--------------+-----+
       | CoAP / OSCORE   |  6LoWPAN ND  | RPL |
       +-----------------+--------------+-----+
       |       UDP       |      ICMPv6        |
       +-----------------+--------------------+
       |                 IPv6                 |
       +--------------------------------------+----------------------+
       |     6LoWPAN HC   /   6LoRH HC        | Scheduling Functions |
       +--------------------------------------+----------------------+
       |               6top inc. 6top protocol                       |
       +-------------------------------------------------------------+
       |                 IEEE Std. 802.15.4 TSCH                     |
       +-------------------------------------------------------------+

                       Figure 4: 6TiSCH Protocol Stack

Thank you, again!
Yatch