Re: [6tisch] MSF traffic adaptation under stress

David Hauweele <david.hauweele@umons.ac.be> Tue, 21 April 2020 16:16 UTC

Return-Path: <David.HAUWEELE@umons.ac.be>
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 C6C123A0D84 for <6tisch@ietfa.amsl.com>; Tue, 21 Apr 2020 09:16:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alumniumonsac.onmicrosoft.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 xAmAtzoa6S1T for <6tisch@ietfa.amsl.com>; Tue, 21 Apr 2020 09:16:49 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150084.outbound.protection.outlook.com [40.107.15.84]) (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 0F9C93A0D68 for <6tisch@ietf.org>; Tue, 21 Apr 2020 09:16:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mbvZj3ihhE/exFnRU9KljLYcv/PoaiGAPgWHmudSfR/bPay3XRqtLf0/Hfz2iyeyyo31FvL6R5jYc/k2jQzYLn7C2b2/bjQklYvwsThrSW75lvtpVOpiU3eZhheMOPyzgWB//673nSCG38UPJxmX6LeZ11CrEgJPQiqNhFZjCjIu6+Ncv9PBUhmMOjP/yJgXVh9xat//qbMpHtBt7Lg3Y8HNAK+Xdh/j6v9ayvjXFTS4G8KWK8bG9/le1oe61s8lODB3AldSUaJToYsICh0hU2FRCx+Ez1iPA9RMslorTxt3Q20h28q6Y03IxRc0TokwR+JYd5qiniBczEEIg3/8MQ==
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=Cwv4PFjIV4RXakWlwr/nkt7ZumKxY1HiT+FXUVkDpI0=; b=B1XPcPLiKDcavAawGeZSBN+PGYKWnpjz1tWIIdB5YQaIOJBD8VmyBtoV3pThcvYWp2ZEw8n6qUuHdFMYgzHw7CVL+Zy20vkGKqSKHk5K5TrEmbQjGI/TgaO8KXgbpOLNWXviYOeYeZBBXreZ/00wpyprO3FyzFK/pUo4doaUYnCZYxhzl3sIFR5AtSeHQY13b/5ACCQjeEpHAQulzN5Z5ZDNMWNz/UMSni+xTe9QPkxhFjxsrzNDn4BOqsp6kS7WQqnDEhEawNNblSzjt/OWaJqQxlzMLDa8VNPnezXuHUaJluDu8AGUNDAHTFRxgnXDmj3aa3U5tATzluya5sUrwQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 193.190.208.132) smtp.rcpttodomain=imt-atlantique.fr smtp.mailfrom=umons.ac.be; dmarc=bestguesspass action=none header.from=umons.ac.be; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumniumonsac.onmicrosoft.com; s=selector1-alumniumonsac-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cwv4PFjIV4RXakWlwr/nkt7ZumKxY1HiT+FXUVkDpI0=; b=vuFh57sb5Cf/9ZSrpbqbw4aFWzMDw6i1bIpGfZj59KtBQq8GKk9cPXjZncV1wtvOotYFndBPeUCCYoPZYpCSrv7o6wsWvJ/ZWYrytGaF5EPGhsWXsSfLIrfs7P7PPal0JcrLmbAM/Y4Fry90XX9rB5K7xOPzV2yPw3NpCgH9LNQ=
Received: from AM6P195CA0078.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:86::19) by AM6PR01MB6168.eurprd01.prod.exchangelabs.com (2603:10a6:20b:e5::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Tue, 21 Apr 2020 16:16:41 +0000
Received: from VE1EUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:86:cafe::5) by AM6P195CA0078.outlook.office365.com (2603:10a6:209:86::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Tue, 21 Apr 2020 16:16:41 +0000
Authentication-Results: spf=pass (sender IP is 193.190.208.132) smtp.mailfrom=umons.ac.be; imt-atlantique.fr; dkim=none (message not signed) header.d=none;imt-atlantique.fr; dmarc=bestguesspass action=none header.from=umons.ac.be;
Received-SPF: Pass (protection.outlook.com: domain of umons.ac.be designates 193.190.208.132 as permitted sender) receiver=protection.outlook.com; client-ip=193.190.208.132; helo=smtp.umons.ac.be;
Received: from smtp.umons.ac.be (193.190.208.132) by VE1EUR03FT049.mail.protection.outlook.com (10.152.19.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2900.18 via Frontend Transport; Tue, 21 Apr 2020 16:16:40 +0000
Received: from gawen.umons.ac.be (10.104.2.68) by smtp.umons.ac.be (10.104.2.84) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 21 Apr 2020 18:16:38 +0200
Date: Tue, 21 Apr 2020 18:16:32 +0200
From: David Hauweele <david.hauweele@umons.ac.be>
To: Tengfei Chang <tengfei.chang@gmail.com>
CC: 6tisch <6tisch@ietf.org>, "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>, Remous Aris KOUTSIAMANIS <remous-aris.koutsiamanis@imt-atlantique.fr>, Bruno Quoitin <bruno.quoitin@umons.ac.be>
Message-ID: <20200421181632.64bad9c4@gawen.umons.ac.be>
In-Reply-To: <CAAdgstQFidyM7ChZZWRX6NMXc_qVK62t-SRem1oSj3kcNTP+dg@mail.gmail.com>
References: <20200410002120.076c63f4@gawen.umons.ac.be> <CAAdgstQFidyM7ChZZWRX6NMXc_qVK62t-SRem1oSj3kcNTP+dg@mail.gmail.com>
X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd12.0)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.104.2.68]
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:193.190.208.132; CTRY:BE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:smtp.umons.ac.be; PTR:exchangehub1.umons.ac.be; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39840400004)(346002)(136003)(376002)(396003)(46966005)(70206006)(4326008)(1076003)(26005)(786003)(16526019)(186003)(107886003)(8936002)(336012)(966005)(47076004)(5660300002)(44832011)(426003)(55016002)(86362001)(54906003)(2906002)(356005)(6916009)(53546011)(6666004)(7696005)(70586007)(8676002)(478600001)(246002)(316002)(7636003)(5001870100001); DIR:OUT; SFP:1101;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 91041910-0aa4-454c-44de-08d7e60f5ffe
X-MS-TrafficTypeDiagnostic: AM6PR01MB6168:
X-Microsoft-Antispam-PRVS: <AM6PR01MB6168FDA3E313038CD0D17C70C7D50@AM6PR01MB6168.eurprd01.prod.exchangelabs.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 038002787A
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: UHOxEWCelKbq4yOyIbG79CUlCZzMZQQW3HazQdzPIj9HCpZQ0nfHNUWrylEAh66tJgf5djVgVbKKL/pybCIgUb/aUil6z2OPHuPNvVxXW4UacLjb8mLIadavQBqvBy9LC7u0gVjpfPOzH+K5MCYVqNxE7ne21uZPwgOAyWm2JnMsrDgZcUGyAgcM+/Sy+4ciCg+S+i+Y+/PkS5kmoJNsLpK0jTYWqo3uXjCw6CsewoSbbycOTO1pmuieUjf0wqbGK6LEdX7r54MzwWmzNMS6TeFmJK+PhxeX29bC6WxpGO9ZwJl3okqNWHbXCdgx8e73JMcP4m2rP51vQ+NsRxnMjFjpu872vBvc3fvkpq59WUst5YH9NGkijWPRu6d232Yxg4EUwYhVCRg2x3KAFmfX3ct9Lxg+nPjl2NluMp5lBbf/Uf5tjJToXrt2EPED2mEOjWJtbnhk053nIMVS6Gg9/dcmXkcLo+N55PobVGnVSaITQ5F7s8D+pMNoIQJzkTM3n3IExMB1c5CaYiRxUVcwERgp4rmzz2ayNdRyexzUQDNRpblI/JCKSeDrPSqq10xM399lXYEbVgzG01tvenSePDQDd5tutwilj8U+ueECvVT/AEUYhsU5M2ZNKiz7v2h/
X-OriginatorOrg: umons.ac.be
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2020 16:16:40.3129 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 91041910-0aa4-454c-44de-08d7e60f5ffe
X-MS-Exchange-CrossTenant-Id: 488bed9d-d6a7-48d5-ba1f-ebec3823b357
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=488bed9d-d6a7-48d5-ba1f-ebec3823b357; Ip=[193.190.208.132]; Helo=[smtp.umons.ac.be]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR01MB6168
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/DHpvENCkGsF0MU36M882qODYymM>
Subject: Re: [6tisch] MSF traffic adaptation under stress
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: Tue, 21 Apr 2020 16:16:56 -0000

Hello Tengfei,

All our approaches are currently work in progress and we plan to
evaluate them in the coming weeks. We understand this is late in the
standardization process and some of our changes are more involved than
others. Here are some of the ideas we plan to evaluate.

Our first goal is to reduce the time required by MSF to allocate the
number of cells for the current traffic. To do so, we could allocate
more than 1 cell per 6P transaction, another change would replace the
recurring window of MAX_NUM_CELLS with a sliding window of the same
size. As a result we don't have to wait up to MAX_NUM_CELLS to issue
the next 6P request but only up to the next cell.

Our second goal is to reduce the overprovisioning of MSF especially
with higher traffic load. To do so, we plan to evaluate changes to the
values for LIM_NUMCELLSUSED_HIGH and LIM_NUMCELLSUSED_LOW and
eventually use dynamic values that depend on an estimation of the
current traffic load.

Best regards,
David, Bruno, Aris and Georgios

On Fri, 10 Apr 2020 11:16:57 +0200
Tengfei Chang <tengfei.chang@gmail.com> wrote:

> Hi David,
> 
> I replied inline:
> 
> On Fri, Apr 10, 2020 at 12:27 AM David Hauweele
> <david.hauweele@umons.ac.be> wrote:
> 
> > Dear 6TiSCH,
> >
> > In the last few months, we performed a small scale study of the
> > behavior of 6TiSCH's minimal scheduling function (MSF) under
> > stress. We were especially interested in the dynamics of MSF's
> > automated adaptation to traffic load. Some of our conclusions have
> > been summarized in a paper that we submitted to IEEE ISCC 2020. A
> > copy of the evaluation section of our submission is attached to
> > this mail.
> >
> 
> Congrats on the published paper!
> 
> >
> > Among our surprising findings, we observed that
> >
> > 1) The time required for MSF to adapt to a traffic change depends on
> > the current number of cells allocated. To give an example, it takes
> > much longer to go from 0 to 10 cells than from 10 to 20 cells. We
> > attribute this behavior to the way MSF measures cell occupancy by
> > counting the number of used and passed cells. Adaptation only occurs
> > when the number of passed cells reaches a maximum. However, with
> > light cell allocation, it takes longer to reach that maximum than
> > with higher cell allocation.
> >
> 
> Cool! I have the similar results when evaluate the MSF performance.
> There are two things influencing the response time to the traffic
> changes 1. The value of MAX_NUM_CELLS, which you mentioned. It is
> configurable. By setting it to a small value, the  response time can
> be reduced in case the traffic load changes frequently.
> 2.  The number of cells to be added/deleted each time.  In MSF, for
> the simplicity, we only add/delete 1 cell every time. An advanced
> version of MSF could add/delete cells according the percentage of
> cell usage.
> 
> >
> > 2) MSF can lead to severe over-provisioning, which can be harmful
> > in an environment where the resources are scarce. We noticed that
> > releasing cells was especially hard for MSF due to the fixed
> > hysteresis thresholds. Indeed, the estimated cell occupancy must
> > drop below 25% for cells to be released.
> >
> 
> The over-provisioning is designed intentionally to avoid the
> fluctuation of 6P transactions.
> It costs additional 50% cells in average, as a trade-off, it could
> reduce the cost of sending 6P frames, and the latency caused by 6P
> transaction. No sure if there is a perfect way to cover every aspects?
> 
> >
> > We already have ideas to improve MSF's traffic adaptation mechanism,
> > that we plan to put under test in the coming weeks. We can also
> > provide you with more details if you wish. If you see interest in
> > our evaluation and proposals, we are eager to discuss this further
> > with the WG.
> >
> 
> Very interesting to see your approach to improve MSF !
> Referring to the MSF standardization process , as said by Pascal, we
> won't be able to made big changes.
> We can adapt some minor changes.
> Unless there is a flaw in the draft, I would prefer to keep the draft
> as it.
> 
> Tengfei
> 
> 
> >
> > Best regards,
> > David, Bruno, Aris and Georgios
> > _______________________________________________
> > 6tisch mailing list
> > 6tisch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tisch
> >
> 
>