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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 02 April 2020 09:57 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 C7FAC3A0EBE; Thu, 2 Apr 2020 02:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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=lo8/sc0E; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZUd/YrdW
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 2nbiDaPFI79X; Thu, 2 Apr 2020 02:57:37 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3516C3A0EBC; Thu, 2 Apr 2020 02:57:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3946; q=dns/txt; s=iport; t=1585821457; x=1587031057; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5wrucF9PJ/BoNwOhv3T03av+cHtBsT/HJlg3aA20+aA=; b=lo8/sc0EA43fBMgRucw2/96op8PlKQPhjN0S7m/cog+QXXLeQIQIdOKW 000XhGaZlkRxG4l/CFJST0mDpsybK4ntFK6FNWUKf5d2k+db/pXFxaCIB jq8fM3uS+Vzb53l0LUnWNUzmZ8lmIB18qnx3IKBaUcHmePS1/Zo+5vPRT A=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ao05aeBJWNhwG1bbiWtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgCQC1toVe/5RdJa1gBg4QAQscg09?= =?us-ascii?q?QBYE8CCAECyqHYAOKbZp9glIDVAoBAQEMAQEtAgQBAYREAoJAJDgTAgMBAQs?= =?us-ascii?q?BAQUBAQECAQUEbYVWDIVxAgEDEigGAQEpDgEPAgEINhAyJQIEAQ0NGoVQAy4?= =?us-ascii?q?BpAUCgTmIYoIngn8BAQWFMhiCDAmBOIUihw8agUE/gViCTT6ECzMSg0KCLI4?= =?us-ascii?q?LiReZZAqCPZIDhTWCf5hzjymcFgIEAgQFAg4BAQWBaSKBV3AVgyRQGA2OHQs?= =?us-ascii?q?YFYM7ihg9dIEpi1sFgj4BAQ?=
X-IronPort-AV: E=Sophos;i="5.72,335,1580774400"; d="scan'208";a="733778330"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2020 09:57:36 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0329vYFE025454 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Apr 2020 09:57:35 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 04:57:34 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 05:57:34 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 2 Apr 2020 05:57:33 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JaozkBQukBmTZmJUUQxBAFLphM/ysh1anYAVCMvTRxbDdkeuqz1cVzKekM6A5CZ+b14h05GVoRVsIjvF92W5a6El2FQikRFOU2niiNwlZqrw7hqY5E+93fVxASuKRE2s1cloXsyQENrjQKH4DlfBlZeVFdGAAeR0WxFcCXSikzIC87IF8QZkH/jzhFOYNaxvNdo0ngCNcAaL/NfJ5TfLmw22lFMnqGRVGLUxAZnXA4HxiRbmbfRRHmRCMBMn41siRy+wzZqbveT6SZn8KT8hcbNVDAuhzHSn+7nJO+deQ6DWejmvUiEWOiZGSX5SA2AsP0sNBCZ8f7Mo8d/EAThRTA==
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=xdgS2EXQiWVkbWSHExKGyDCcg3d9IZRoDWicd3JCojg=; b=YheT2KiCeSdl/t/wMsI1st9B9aLPxcVYuuwF5LGcvGMpWLAO/YPo/9fhwEfT03+npka1/1nwyADe+Kt4QpHkweoAD+wMdfyEHuiQVyEO++NYvraqV3kcGEToL07E/1NNAY6aLtLmj7sjSKnr+DADRsKrzF3pnKIPkYupyl0xTLApEAifZi4ccg7q4tGm4LAUw8/C+TXxNM8+NouXzmO6XkNQzHl7iU2+qCL4QN9ks6t3BkKZxswA4RdBCSHzYNhrNj3HO6pqI5q6uNfvC0KaAEoC5Pc7qZFvrDUlkYk02wO12xpt7HFAgHeZetpYQtmvMsxDB+7u6xXZyMQdLPs38w==
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=xdgS2EXQiWVkbWSHExKGyDCcg3d9IZRoDWicd3JCojg=; b=ZUd/YrdWL/CIwuzzTD7V4j7p8+zkXw9iHts9eHD1nOA3dYVz5GgZkzMTTX8OQ1GMDSFsW7zD8h1T3wYO9dT4TwphED9wMUurleBeS9G80vm+wuciu4JRP2jsSoQmhS8lQdguInK6JAq/bEVPNcvyCl5AXGl+UQx9BKDOVHKPxfI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4430.namprd11.prod.outlook.com (2603:10b6:208:192::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Thu, 2 Apr 2020 09:57:32 +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; Thu, 2 Apr 2020 09:57:32 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Tengfei Chang <tengfei.chang@gmail.com>
CC: 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+mByFf4Pi6g==
Date: Thu, 2 Apr 2020 09:57:07 +0000
Deferred-Delivery: Thu, 2 Apr 2020 09:56:14 +0000
Message-ID: <MN2PR11MB3565D75EADFF279B8A03B577D8C60@MN2PR11MB3565.namprd11.prod.outlook.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>
In-Reply-To: <20200331235734.GU50174@kduck.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
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:4102:5cf3:7a8b:235b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ad9da32b-762c-4587-88e0-08d7d6ec4346
x-ms-traffictypediagnostic: MN2PR11MB4430:
x-microsoft-antispam-prvs: <MN2PR11MB4430AF9A0FDB89922D51FBFBD8C60@MN2PR11MB4430.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0361212EA8
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)(346002)(376002)(39860400002)(136003)(366004)(396003)(186003)(6506007)(66556008)(86362001)(6666004)(76116006)(66476007)(54906003)(71200400001)(316002)(66946007)(4326008)(55016002)(64756008)(9686003)(110136005)(52536014)(66446008)(478600001)(7696005)(33656002)(5660300002)(81166006)(8936002)(81156014)(2906002)(8676002); 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: 5NffxwRe1v+RHwRugURZAFsxh1AtpFZKEz9x8mMydiYCWGtRtkFxcRPlDIu1Ax6an2a0on5EpAMbqfQ7u4GdMdbW4Y4fj5QLRCaaCHoLMB9GMmhyj4LTesn0n7fsr3ZKSKVfoeSZGqEXduvOE0J/R31H1JWStax1sWB4iFlgffgWltLq8T7jbjUr73LydXrYBfFxKk7ihk+98PDD6DWLrfh7D8nw1huVWbwq+FbHLDUm634m5yWyfxxmSE0sW0uuINvl+dEjD34FW4RidwB34krtbI9x8H47T/WDDtXuIXFjz6VPTf0bcPcM5/12h2EtvI8L/ERJTNkBFeakIQr2DW0KaokHEe/NUOA5E4U6SiSs7A9SiXpjhZ6D4MXh49q272yUFu/XEy3Y1bTwTROoqBjZuyHCR9MaBc6gGJ4cbTLR+AJAXcLdQueclzUPJM5a
x-ms-exchange-antispam-messagedata: vbQIBazrPbqGH5fjFLnf6JUo0nf+uT5s3O2ZHlVjTd2CojpLzvu47Emjemrb4zdvGB2htyvgJ5al10OZ8Fxye7ia5IAalsnKE1vdTBfmAt7+IWFd+yn6VAhzHBmyjPI+e4iwcXa7ggPyncU4ZDnvHn8JsCrqbF/fxOWkPCHAYdcfpesmsHL7orCrnYpsNDHI+B01A9n+TpzYBnk6JzhakA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ad9da32b-762c-4587-88e0-08d7d6ec4346
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 09:57:32.3587 (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: xBV9YaOw0/1msuxHrN/E8PgT8EeqqvRssjtbsc/sTc2jogTmcwgmiuGTaKfiH73tetBSzSQmJygctcXiXiOCMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4430
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/3OPeZ7-rbgKMMFLO91seS89RTyk>
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: Thu, 02 Apr 2020 09:57:39 -0000

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.

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?

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.
>