Re: [Roll] MPL leaf node behaviour

James Ko <jim.list@hotmail.com> Wed, 30 August 2017 07:49 UTC

Return-Path: <jim.list@hotmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7FC132386 for <roll@ietfa.amsl.com>; Wed, 30 Aug 2017 00:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.125
X-Spam-Level:
X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 Ga2GT6StVlkG for <roll@ietfa.amsl.com>; Wed, 30 Aug 2017 00:49:49 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010016.outbound.protection.outlook.com [40.92.10.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93971326FE for <roll@ietf.org>; Wed, 30 Aug 2017 00:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aa2dVzC1La+/o1GiFyIWSX3oAsXBM07CjNMIQXrG8ns=; b=NnnO3ZACevlP6oHmXZVRnYnAgzWldKyXllo7oJxfD82EjxjlRDCfetr4G7YTSIH1GdD84ZoqRQSnkS3oDooDJ0GRSRXKJO0YyVqKP3MKuNgZtzXgzYCe6BqET9RMi3qg8lnQ36y/s3Ek/ppfyfNKetW6wLWjo2yi0Uk3LyzRaGAqcJUno5sVUlu5z/hcwhwUMwMsNO2XYqH/66Jk5kbQWrCHhiXz3qMS9zgavtosxQKUbgwvWpnKc6AhQLMXCI7jy/hpG8tey8Xv4TnClTFri3xsO1HsxdfsHlkAj/Zb7eeDGrHi8vbYUONqDD7YYebORqR8/InzLSX+r8ypwSbDwQ==
Received: from CO1NAM04FT022.eop-NAM04.prod.protection.outlook.com (10.152.90.56) by CO1NAM04HT222.eop-NAM04.prod.protection.outlook.com (10.152.90.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1341.15; Wed, 30 Aug 2017 07:49:47 +0000
Received: from CO2PR03MB2198.namprd03.prod.outlook.com (10.152.90.58) by CO1NAM04FT022.mail.protection.outlook.com (10.152.90.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1385.11 via Frontend Transport; Wed, 30 Aug 2017 07:49:47 +0000
Received: from CO2PR03MB2198.namprd03.prod.outlook.com ([10.166.92.21]) by CO2PR03MB2198.namprd03.prod.outlook.com ([10.166.92.21]) with mapi id 15.01.1385.010; Wed, 30 Aug 2017 07:49:47 +0000
From: James Ko <jim.list@hotmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Thread-Topic: [Roll] MPL leaf node behaviour
Thread-Index: AQHTIPdoOvPaLEa6KEWDiBVeON4mEKKcfIkAgAAKobY=
Date: Wed, 30 Aug 2017 07:49:47 +0000
Message-ID: <CO2PR03MB2198C455FB6A3727108F82C0FD9C0@CO2PR03MB2198.namprd03.prod.outlook.com>
References: <CO2PR03MB21988E7723DCD47ADCBB95AEFD9F0@CO2PR03MB2198.namprd03.prod.outlook.com>, <109cc707217eef50b9a48b9eb6b353c4@xs4all.nl>
In-Reply-To: <109cc707217eef50b9a48b9eb6b353c4@xs4all.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:5F9BFBDBEEB6EC896711622D5E24698D1BA94444E091B4FC04124402C3DE3627; UpperCasedChecksum:B27A7EB8883726AC1BD7BB6039FAADB8D8093EAFB0CB960324DB879139511EA1; SizeAsReceived:7083; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [Ei/axijBqW0fW9qfePZxhQ9n33Qj0vYz]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO1NAM04HT222; 6:o3MtGf1OQYnENOfDirpIJx6oB6ahF8jpSbiIV9NXXr4FazM1XWqh8MMn0IE0XF2cXvC2LATuwU+n5qWFzzQjNZpKx9SDnh5F7RX6QmqiZ72aRMRhC7zJR34lrAhDiNVQnPDmxSJoW0BoZlSDm4iIjW656LFwSD2r1hNRSO5SAeOxCG4JuXKlsfTrxgW17FOhFJH/XeFbWAKZnot/3JXDsHFyEHruqzyS2EiYpNUGmPLPB/txgkcfDdx+NZeWEc7EuY2LYt4GpO4u8UW6uAIAo+/uAf9QNECnFl0njI3HdzKDHr0f/33vIPRCR2PLWTSN7m6W33IGEbkha5Yhv/Uwbg==; 5:vZ+xnh0MqxTpzJDDolgUtVv4zQY72IIwvX0cIllt8t89AMsCb+qyKVBdsBqbmIcbwxx7QKBsN5XX4MIzyEZzVqw9Y35Oliy+ScPk1qdTjdZc61mGV1ByGRs8y+YzXN5c9Lg7HzMJMNSkUOyOW/6VpA==; 24:FQfkVt+TWv84c/6cCBOYxKGzDoHOnY1HNdwQ2glUvYuctNRW74O5JYqctlhmjUNhQ0ZnHxyLWawHWi2Warr4Qw1dXuYUIDD/oyZBM9eguz8=; 7:kg7cSptoPqNxRBLdiL+fWKm68dE7B05P9zluAtmz7SzYlRmLI6PUjLguhTvD5p2Lshu2toc4JN/2+rZQGhMAXqP01GUtaPcaGWyhEOy+tdKjRZ1J4DAGJ+POyQuVV7XP04aga4nu6oAFOgUTNtX6KaBWLLMwU19Tfdr110D3/2x5Crb+Tn77Fsfz+b+UoG8HvvHo8hsoeLGqesAtbdEo/42o62DRcjgSlAw0YgABj0s=
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: ced4676c-fa1f-4ffa-fb38-08d4ef7bafc1
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO1NAM04HT222;
x-ms-traffictypediagnostic: CO1NAM04HT222:
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:CO1NAM04HT222; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO1NAM04HT222;
x-forefront-prvs: 041517DFAB
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM04HT222; H:CO2PR03MB2198.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CO2PR03MB2198C455FB6A3727108F82C0FD9C0CO2PR03MB2198namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 07:49:47.3105 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT222
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/TyIYfqW_awDOC-lpnP2yc8tu3B4>
Subject: Re: [Roll] MPL leaf node behaviour
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Aug 2017 07:49:52 -0000

Hi Peter,

Yes.  TX[1] is data message with sequence number 1.
The new interval is started with node 1 sending message 1.  Node 2 receiving msg 1 and retransmitting it.  c is set to 0 on first TX/RX and reset if an inconsistent transmission is received.  There are no inconsistent transmissions shown in my example.  For each consistent message received the count c increases but the edge node doesn't receive the same number of consistent transmissions as the other nodes.

For low powered nodes at the edges of the network this atypical behavior would unnecessarily consume power and bandwidth.  Are there recommended it best practice strategies for edge nodes to achieve c>=k.

James



From: peter van der Stok
Sent: Wednesday, August 30, 00:11
Subject: Re: [Roll] MPL leaf node behaviour
To: Routing Over Low power and Lossy networks


Hi James, Does TX[1] mean the sending of message 1? When is the new interval started? c should be reset to 0; I don't see that happening. And yes, MPL continues sending till the maximum number of events is reached or the message is too old. Is node 1 the seed; does it resend as well? Setting the max number of events to for example 2 will help, but is reliability assured then? At the edges of the network you may expect atypical behavior compared to the behavior of the other nodes related to the evolution of c value. Peter James Ko schreef op 2017-08-29 20:51: > During testing of my implementation of MPL I found that the leaf nodes > in a mesh network (or the last MPL Forwarder to receive a multi-cast > packet) would continue to retransmit at every trickle time 't', until > expiration 'e' is reached, since it does not receive the same number > of 'consistent' transmissions from a neighbour and count 'c' never > reaches the consistency constant 'k'. > > Example with k = 2, seq [1], nodes > > Node > Node > Node > > TX[1], c = 0 > RX[1] from , c = 0 > > RX[1] from , c=1 > TX[1], c = 0 > RX[1] from , c = 0 > > TX[1], c = 1 > RX[1], from , c = 1 > TX[1], c = 0 > > RX[1] from , c = 2 > TX[1], c = 1 > RX[1] from , c = 1 > > RX[1] from , c = 2 TX[1], c = 1 > > RX[1] from , c = 3 > TX[1], c = 1 > > RX[1] from , c = 4 TX[1], c = 1 > > Node would continue to retransmit [1] until 'e' expirations. Even > if reactive forwarding is enabled (CONTROL_MSG_EXPIRATIONS != 0) and a > 'consistent' control message is received it does not increment 'c' for > the data messages. The data message trickle is reset only for > 'inconsistent' messages identified by the control message. > > If the expirations 'e' is large, what, if any, strategies could be > used to prevent the leaf node from continuing to transmit since it > never receive k number of consistent transmissions? > > One possible strategy is if reactive forwarding is also enabled then a > data message should only be transmitted if 'c' < 'k' for both the data > message and the control message. > > Of course, this leaf node consistency problem also exists for the > control messages following the trickle algorithm. > > James > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll