Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 03 April 2020 05:49 UTC

Return-Path: <pthubert@cisco.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 8132D3A1002; Thu, 2 Apr 2020 22:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.589
X-Spam-Level:
X-Spam-Status: No, score=-9.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IrNhzs/0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RMzH257I
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 vlXy5oKxOoH9; Thu, 2 Apr 2020 22:48:55 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C8A3A1000; Thu, 2 Apr 2020 22:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7690; q=dns/txt; s=iport; t=1585892935; x=1587102535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eMUAhVFGgqEyHn7vAUKsOGb3XcvvY/opr2x18gVjEOo=; b=IrNhzs/0EW8WQb7It2vSQOD7T2cD2ajRUGxNDzAdkaniik0CCtnH2FEE lvxc3tN0Qg6yiYfQ0QRavAmEdGV/YVm/Untp0RXkmb8eV0h/pQYoZvVB2 Ee0k9R2OAivP3g17T2kRn5pZhhkcksvV21IWl50wkSIEf5PrCQ7OSAmf4 M=;
IronPort-PHdr: =?us-ascii?q?9a23=3A7p1hDhyC3intSPfXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6BQA3zYZe/4cNJK1gBg4OAQEBAQE?= =?us-ascii?q?HAQERAQQEAQGBe4FUUAWBPAggBAsqhBuDRQOKa4JfmB6CUgNUCgEBAQwBAS0?= =?us-ascii?q?CBAEBhEQCF4IqJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQIBEhERDAE?= =?us-ascii?q?BKQ4BBAsCAQgYAgImAgICMBUQAgQOBRsHgwSCTAMOIAGjeQKBOYhidYEygn8?= =?us-ascii?q?BAQWFQBiCDAmBDiqFIocPGoFBP4ERJxyCTT6ECzMQgxIygiyODII8O4Ygig6?= =?us-ascii?q?PWQqCPZIGhRkdgn+YeqtHAgQCBAUCDgEBBYFpIoFXcBVlAYI+UBgNjh0LARc?= =?us-ascii?q?VgzuKGD10gSmLeQWCPgEB?=
X-IronPort-AV: E=Sophos;i="5.72,338,1580774400"; d="scan'208";a="457627976"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2020 05:48:51 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0335mpXp030501 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Apr 2020 05:48:51 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 00:48:51 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 00:48:50 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 3 Apr 2020 01:48:50 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LWuCEKw0dVcd4oJjWq30FqtcZq2PJqpTpnoOksiYk6hr6nEXwwEVf4ID+39MXMa/pevnlHF8NXWA3aq8IJGeGTrvavQJ9yYta1fexm6RMa9v9o1WWuF+PMAwa0+U30FWVuEhVqKe0TN+4PDsSmIfi5Ns3S87UabLVSM++lpQr2YLinDwoRNrfq5uGYmpzAQbZ8/jxc08FhEuEEW2GvoI4XPy6vd/B38GPQhGAyLoZKu24yLxLWFkSEJluagM+m4nBetnjVF+GEQdf593yfscg1dmAlPubbBY1QFVm3+lCvr1j3WgFeRZzT4adU+TgRXjGe1MXcTWseBt1GL3A254LA==
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=eMUAhVFGgqEyHn7vAUKsOGb3XcvvY/opr2x18gVjEOo=; b=FLWCNn8e0oZxelPJGu98OduluZ22HLjH4ig7iAy926Bmo4n497ctVNmirOHIbiVQruRRR9sKlL6nB5LiJc8yxc5phSUi7ILejhyAreQa1ZhpdOdWpaYQngJxOaqixh6oIZoz1hVVR5qztyY/L2EquoaYN8whIfCpTeo2/eHQzG+DH8O7s4u/CVfY4rArL9xipFQCQJmngs9174mDwBENxTiYqsMZCA/8aQSijZBJcfDQt+dDp8iVGoklILnggV3Qe/P45lQh87iTg9tYG+EZmN0gkl/fiGgomdyajLMnpQV74JWG0wF67ydEFi9w8gVa5HFRmyZu8cNLyEelVyNOAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eMUAhVFGgqEyHn7vAUKsOGb3XcvvY/opr2x18gVjEOo=; b=RMzH257IuU6gBX8qUwFLdR6u9uRw/z2csZphn1OUQvgiujvXjcDTfnCiA5ORsO2GwmCXHIPOBaQK5stzTvX634i1zJ/JmHhVcO11SX4RtiKa0qC4CmRZ9h3xa2GFpdWsGV1jsj+qb1Ybj/yoWKxS+97pqlHP2JuvvePNJAICSf0=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4629.namprd11.prod.outlook.com (2603:10b6:208:264::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 05:48:49 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2856.019; Fri, 3 Apr 2020 05:48:49 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Tengfei Chang <tengfei.chang@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-6tisch-msf@ietf.org" <draft-ietf-6tisch-msf@ietf.org>, 6tisch <6tisch@ietf.org>, "6tisch-chairs@ietf.org" <6tisch-chairs@ietf.org>
Thread-Topic: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)
Thread-Index: AQHWCNTOIgQ9Wkcjr0O+mByFf4Pi6qhmwKsAgAAkwxk=
Date: Fri, 3 Apr 2020 05:48:49 +0000
Message-ID: <A87B4EFC-1DC8-4A0F-AE5A-089F8DB33B4B@cisco.com>
References: <158394932747.1671.4699004253009791924@ietfa.amsl.com> <CAAdgstSMOf7wDSfbWMv5tEzpx1=otQZX_TZ+Xevm77f-1ZztNw@mail.gmail.com> <20200324192510.GE50174@kduck.mit.edu> <CAAdgstTzBTwncFgaEao62X2s4J610_spy4oFsTYNkB1KUKhHww@mail.gmail.com> <20200331235734.GU50174@kduck.mit.edu> <MN2PR11MB3565D75EADFF279B8A03B577D8C60@MN2PR11MB3565.namprd11.prod.outlook.com>, <20200403033714.GF88064@kduck.mit.edu>
In-Reply-To: <20200403033714.GF88064@kduck.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:8d91:7397:17d6:dc84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 49c39c6e-a15e-4af0-6161-08d7d792aeba
x-ms-traffictypediagnostic: MN2PR11MB4629:
x-microsoft-antispam-prvs: <MN2PR11MB4629F4B945DB858E8C457B78D8C70@MN2PR11MB4629.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0362BF9FDB
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(346002)(366004)(376002)(136003)(396003)(81156014)(33656002)(8936002)(66946007)(91956017)(36756003)(66574012)(2906002)(2616005)(76116006)(8676002)(478600001)(71200400001)(4326008)(316002)(186003)(6916009)(6486002)(6512007)(6506007)(81166006)(66556008)(54906003)(66476007)(64756008)(66446008)(86362001)(5660300002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8jxEx/HuGx6Bc49j9dPVPsp9b83ZC75WvXyFPFe5rIRciizLJMe/Lhkg+sDlsciYkPHWeWkib/5P7Z3paNn9T06Cmm0eAc1PDc02HkJqV/xefSSoISkJsVaf9ps3nhiSqBU4ptjzaJ4gj8zubmMNU2H7jhlk9riBQpNPsbV8F+s4RsCatlrSxoWLi+/CnP3SKRB8MoMlO8QENAPIaxdfX6mU1ith7qw+9tsyjyrYGpLePU9YPQFFXQWZEjjQV3ZoeQ5yM6y48LVvaVgf4ANz7T4cgI3tJ0y1Zvze1y9CfdPEBRpg8Na5cMwbntO52JBGH0CbtVRKarI1SIMvk8yqk/kWmryDQN9fx/gnS4YDGNKB0ZRtsNipC2BL3fq+Ydb799f7Ney/bWufRAu2sZ8KVnf3QqiwNSANrNvcwmeUVUmOBq9lBVytzW/2nXsEjx5K
x-ms-exchange-antispam-messagedata: Y1RfsUif3ousReUSuUWNdLzwQjas6p5Fa5EqranYV9JsyPshnDgGUly6n/AzC/aNwYtAcB70QAzx4knOrBxFH0qm/R0uwNytUQHas0l1/mqz09ge2LNeKr7chq64/LFpLem03KJk370Zrpc5RCodNWXTXc/Bpmh2Mebvx95Nu7vLZwkfWdhKxWq1yjNa37HZHAOAKtRdwnQKHn7+bkYXLA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 49c39c6e-a15e-4af0-6161-08d7d792aeba
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 05:48:49.1662 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ip2cHRHw0X02DMPL5RP1FZwM6ufNMAI8XdZS32SMXZND0lPyN02rODQftatzHn3HeDh+MAUL+7Kn2hosJtWY8Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4629
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/UgBzf4Cn7wu9Pe__zafgPKDOewY>
Subject: Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)
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, 03 Apr 2020 05:49:08 -0000

Hello Ben
´
> Le 3 avr. 2020 à 05:37, Benjamin Kaduk <kaduk@mit.edu> a écrit :
> 
> Hi Pascal,
> 
>> On Thu, Apr 02, 2020 at 09:57:07AM +0000, Pascal Thubert (pthubert) wrote:
>> Hello Benjamin and authors:
>> 
>> Thomas is really the MAC expert, (virtually) collocated with him, and more fluent in English than I'll ever be. But I'll take a chance at it.
>> 
>> I understand that the problem you're concerned with happens when the automatic slot offset for node A ends up the same as that for node B. Note that it does not take a hash collision, because the problem is independent of the 
>> channel offset. All it takes is a collision in time, because if I'm busy transmitting I cannot receive on a half duplex radio. The chance of this to occur is 1/slotframe_size for a random pick for which the hash is an approximation.  
>> 
>> In that case (same auto slot for A and B), an arbitrary node  C (which could be A or any other node) will fail to talk to B if B has something to transmit to A, because if B xmit has precedence, and when B's radio is busy and it will not to receive from C, even on a different channel (it's half duplex). So if B keeps talking a lot to A, that will make it mostly deaf. But if B is a relay as opposed to the generator of traffic, the xmit queue will dry out and B will listen again. 
>> 
>> If C is A, meaning that A sends to B and B sends to A at the same time, and in the absence of other traffic, the retries will happen at different times and will not collide, all good. If the traffic in both direction becomes intense, the retries will cause even more collisions and we'll end in congestion collapse.
> 
> The "retries will happen at different times" is the part that I was
> missing, and Tengfei just added a description of that in the -16, so I
> think I'm all set as far as this goes.
> 
> Thanks for the detailed explanation!
> 

All good then; I misunderstood and thought you expected a finer description of the case in the spec.

>> Potential defenses include:
>> - MSF could be more aggressive at establishing cells to nodes that end with the same automatic slotOffset as self
>> - In densely used networks (which are unusual for battery operated networks), define multiple timeslots with different auto slotOffset for each node, using different seeds for the hash (like a nmber 1 ..n),  and have the sender use a random one for Tx.
>> 
>> Is that what you are after?
> 
> It's not clear to me that we need to mandate either of these as part of a
> *minimal* scheduling function, though having a description of the potential
> issues would be reasonable.

This is what I expected, though it is not a security issue per say, it is still a pitfall that the deployment should be aware of. Also the reader may have the same intuition as you did and having the description handy makes sense to me. That could be an annex though. I did not expect to mandate solutions just to express them like we do in a security section. Note that renumbering is another remediation and still an open question in your COMMENTS.


>  (Should we expect higher-layer protocols to
> eventually back off and remedy the congestion collapse?)
> 

I’d not suggest that. It would work but misuse the network and waste energy.

 The root issue is not the load between A and B but the MAC addresses that they picked and the shape If the mesh. IMHO this should be addressed under IP.

> I'm going to go clear my Discuss now, as those points are resolved, which
> of course does not preclude making further changes.
> 

Many thanks Ben!



> -Ben
> 
>> Thomas (or Simon): I'm sure I'm missing stuff, what more is there?
>> 
>> You all keep safe
>> 
>> Pascal
>> 
>> 
>> 
>>>>>>     DISCUSS:
>>>>>> 
>>>>> --------------------------------------------------------------------
>>>>> --
>>>>>> 
>>>>>>     I'm concerned that the scheduling function for autonomous cells can
>>>>>>     cause an infinite loop in the case of hash collision -- Section 3
>>>>>>     specifies that AutoTxCell always takes precedence over
>>>>>> AutoRxCell,
>>>>> but
>>>>>>     if those two cells collide, the corresponding cells on the peer in
>>>>>>     question will also collide.  If both peers try to send at the
>>>>>> same
>>>>> time
>>>>>>     and the hashes collide, they will both attempt to transmit
>>>>> indefinitely
>>>>>>     and never be received.
>>>>>> 
>>>>>> 
>>>>>>> . Notice that the AutoTxCell  is a shared cell, where the back-off
>>>>>>   mechanism is applied.
>>>>>>> In case there is a collision on that cell, a back-off with different
>>>>>>   exponent will be used on each side.
>>>>>>> The cell will be used AutoTxCell on each side at different timing.
>>>>> 
>>>>> Ah, it seems I was misinterpreting "take precedence over" to apply
>>>>> to the entire local scheduling, not merely the case when independent
>>>>> tx and rx scheduling land on the same cell.  Thanks for clarifying
>>>>> here; is there anything useful to say in the document about how even
>>>>> if there is a collision in the assigned slot there's still a Tx
>>>>> backoff, so the cell is usable for Rx some of the time?
>>>>> 
>>>> 
>>>> * RESPONSE: * We could add the following sentence right after the
>>>> hashing collision statement:
>>>> 
>>>> Notice AutoTxCell is a shared type cell which applies back off mechanism.
>>>> When the AutoTxCell and AutoRxCell are collided,  AutoTxCell takes
>>>> precedence if there is a packet to transmit.
>>>> In case in a back-off period, AutoRxCell is used.
>>> 
>> 
>>