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

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Thu, 05 December 2019 17:26 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 45B581209A4 for <6tisch@ietfa.amsl.com>; Thu, 5 Dec 2019 09:26:01 -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 RkTUqO44w3BI for <6tisch@ietfa.amsl.com>; Thu, 5 Dec 2019 09:25:59 -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 2070712099B for <6tisch@ietf.org>; Thu, 5 Dec 2019 09:25:58 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,282,1571695200"; d="scan'208";a="331502743"
Received: from roc018r.vpn.inria.fr (HELO [128.93.183.18]) ([128.93.183.18]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Dec 2019 18:25:57 +0100
Cc: yasuyuki.tanaka@inria.fr, 6tisch@ietf.org
To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
References: <CAAdgstRGHyRKoMLBhRih8yHwDvf-DTp42ZTEBmBP57FSgt8MyA@mail.gmail.com> <00c074fd-2423-1620-a7d1-3a899bbd000e@inria.fr> <8D2F7CA6-31BC-4091-8358-F7C86A0A5B37@inria.fr>
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Message-ID: <ddfdfcad-d3ee-99b6-eb60-19b3d33acca7@inria.fr>
Date: Thu, 5 Dec 2019 18:25:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <8D2F7CA6-31BC-4091-8358-F7C86A0A5B37@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/-_CseXA-CGmFPtgKGuxkXhK2Tw0>
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 17:26:01 -0000

Thanks, Malisa,

Then, why cannot the IPv6 layer on an intermediate have rate limiting in 
order not to forward too much packets having AF43...? Forwarding 
decisions are made at the IPv6 layer.

Even if the intermediate node drops excess amount of forwarded join 
requests, the scheduling function in use still needs to do something? I 
may be confused...

Yatch

On 12/5/2019 6:07 PM, Mališa Vučinić wrote:
> The “join rate” parameter takes care that any single JP at the edge of 
> the network does not inject too much traffic. But this traffic is 
> forwarded along multiple hops towards the root, and therefore gets 
> aggregated with (join) traffic from other JPs in the network. The 
> purpose of the traffic tagging mechanism in minimal-security is for such 
> nodes, closer to the DAG root, to avoid allocating cells in response to 
> the join traffic.
> 
> Mališa
> 
>> On 5 Dec 2019, at 17:48, Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr 
>> <mailto:yasuyuki.tanaka@inria.fr>> wrote:
>>
>> Why can't the "join rate" avoid such undesired cell allocations? If 
>> the join rate is properly configured, incoming join requests don't 
>> cause such allocations, do they?
>