Re: [6tisch] MSF Shepherd review

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 06 December 2019 23:00 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 B51181200FE for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 15:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=Q0rl9vO7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bszbUO/V
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 2dpT5zWMvAH4 for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 15:00:37 -0800 (PST)
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 82DAE1200A3 for <6tisch@ietf.org>; Fri, 6 Dec 2019 15:00:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19501; q=dns/txt; s=iport; t=1575673237; x=1576882837; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CpSQqYLmI3JS8GCK1zI7g+f2/lKn8uJcNRABQS0Y+TA=; b=Q0rl9vO7fT/Ib3qF38znmGJ4lYXyoTafIf/d6+pJ5jRLjLJclTeaONbL uR8PN87fMcbK1AXYGqJEGN1HxJtem7pRTrIHmYGVcaKIiAj36Epdv5q6H HdYxZmLO1ntGhbwpEasG/bSrje6/xLtX2xnlxoZXnoGwWdP67vbR3y3ft 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3AeaMtuB0M3p7aGFNOsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AACi3Opd/5xdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWwFAQELAYEbL1AFbA9JIAQLKoQsg0YDiwGCOiWBAYhaiUiEYoE?= =?us-ascii?q?ugSQDVAkBAQEMAQEYAQoKAgEBg3tFAheBfiQ2Bw4CAw0BAQQBAQECAQUEbYU?= =?us-ascii?q?3DIVSAQEBAQIBAQEQER0BASUHCwEECwIBBgIYJwMCAgIfBgsUEQIEDgUJEge?= =?us-ascii?q?DAAGBeU0DDiABAgyQRpBkAoE4iGF1gTKCfgEBBYE1AYNkDQuCFwmBNgGFG4Z?= =?us-ascii?q?8GoFBP4ERJwwUUYFGNT6CG0kBAYF6FhGCUjKCLI01gnKFUIlOjlNDCoIukUe?= =?us-ascii?q?EHhuaMZkkj1ACBAIEBQIOAQEFgVkIKoFYcBU7KgGCQQlHERSMZgwXg1CFFIU?= =?us-ascii?q?+AXSBKI1QAQE?=
X-IronPort-AV: E=Sophos;i="5.69,286,1571702400"; d="scan'208,217";a="664612638"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 23:00:09 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xB6N06aH004509 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 23:00:08 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 17:00:05 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 17:00:04 -0600
Received: from NAM02-BL2-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.1473.3 via Frontend Transport; Fri, 6 Dec 2019 18:00:04 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HHQglKAhSXXebeBviYtzV2ffgtFAP2l16cdv58xjHFZT56kgnfiE2XA0s95+x8hL4BCfbGr5ljsf7UiuhO6/d2MWiRNG1b9jxey5fqe1rdM6zMfOnmbeNGq7SqBKG+CRkgVi1w10RMLxMdPun67xuleehb7S7FFXYOTKjabgBzVcEZU/6huRE43obcD+39rBxCeMNgCloU6UDVvr5N5f6h43hHQk2adNTw25Hm4B9H5l3kv8lnHpxTzgJLcUqUTWL5xAq+70A6FWzqXBviYWL4JivjBbFbKpw7cnF6xoTK2iQlPJf72mhZ3Wotd8KdALW/cwXxvY2cOY+KkEM1RjLA==
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=CpSQqYLmI3JS8GCK1zI7g+f2/lKn8uJcNRABQS0Y+TA=; b=e3lQtFzUk2+nFXyPCmVIBO33TIQWume4Dezz+kNJgEll/XqJ/F+917ERDw5k27qKNaMZy5lWgctR45Ppcw+R4VITc1ruMvF7lF9ic+eD6Y+j8xX4dRi3AEla9bdO0D6MafORhx8ITJ2zRJES9y8s+0vV/zTEoJZ8m9FrPaceric5LUWa7/dGfZWTPPhxcxs/upSoX4X5ffZ+5FLoUJ42UbEQnl1cun6a1kDbSeU3eJ3zt4/s7q5DVwYHcG4a1CibMhcOvXsy90yfX0QeFLUUZemvPY/saNqv1YNcM7hnHRxHxogOBLOYTpel2mTD7RCs4pNMZpeJc3FotanniBToBA==
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=CpSQqYLmI3JS8GCK1zI7g+f2/lKn8uJcNRABQS0Y+TA=; b=bszbUO/VCvo/oyjqXZb2MEnaCIU1aoTIRybaGetspvKmoYNNY8eZJ3HXOVvT4HzcoP2Oewt/CY3/gsZf6qF6a/D636S3yf5daxsqOcQOP6ixQ1YN7fb/KKn+Ad8KBjaGpQjc/pouEX9gGyJ+hHIczZCOvQpkgHMNq2CLZ2Ou2Go=
Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB3687.namprd11.prod.outlook.com (20.178.239.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Fri, 6 Dec 2019 23:00:03 +0000
Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e5b0:1702:87b:b1e]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e5b0:1702:87b:b1e%5]) with mapi id 15.20.2516.017; Fri, 6 Dec 2019 23:00:03 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tengfei Chang <tengfei.chang@gmail.com>
CC: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>, "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: [6tisch] MSF Shepherd review
Thread-Index: AdWjt32cGBMVZwIGSJOTOBd/TtCApABq++aAAADPtX0AWG0eAAAAIxWEAAkDh4AAAdsskwACi4EAAAOiD2kBWKs3AAAGRn/n
Date: Fri, 6 Dec 2019 23:00:03 +0000
Message-ID: <1B030D74-9ABE-4881-9B50-55E67AC0784F@cisco.com>
References: <MN2PR11MB3565642A73EC6629FA68137DD84A0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAAdgstRhP2aOfekS5swmXPbD1rwnR-bAAm9ToBQnwmv77KCSEw@mail.gmail.com> <27392BE1-0C67-410D-B1BC-1F751CC8656C@cisco.com> <CAAdgstRQGMg0fDUH94T+NZQ+s4JM8Wo=xDb+VMQ-sHDKvh8oiQ@mail.gmail.com> <6F9E85A6-B561-41CD-9E3C-7E6E761349B7@cisco.com> <80a20be0-c495-bed6-548c-f909161a7102@inria.fr> <C9BB553F-4531-4875-AE17-68237DCD576F@cisco.com> <4648c9eb-8b44-e62e-970a-6a8ceed800ce@inria.fr> <C2217F07-2C7E-4DB4-80E3-7AD6A9136DAA@cisco.com>, <CAAdgstRCbjt9-g3JA_9Yc1_o+rgu1bCj8=fpY9dUWG+ZPKNnEA@mail.gmail.com>
In-Reply-To: <CAAdgstRCbjt9-g3JA_9Yc1_o+rgu1bCj8=fpY9dUWG+ZPKNnEA@mail.gmail.com>
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: [2001:420:30d:1254:3826:b11a:540e:131b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be529439-329b-464d-8015-08d77aa0079e
x-ms-traffictypediagnostic: BYAPR11MB3687:
x-microsoft-antispam-prvs: <BYAPR11MB3687A8131F25FD7DA3C44350D85F0@BYAPR11MB3687.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0243E5FD68
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(376002)(366004)(346002)(189003)(199004)(186003)(4326008)(102836004)(6486002)(76176011)(36756003)(5660300002)(66946007)(99286004)(54906003)(66574012)(33656002)(53546011)(66556008)(2616005)(66446008)(64756008)(6506007)(966005)(6512007)(76116006)(71190400001)(71200400001)(229853002)(54896002)(66476007)(86362001)(81156014)(2906002)(8936002)(81166006)(6916009)(478600001)(316002)(8676002)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3687; H:BYAPR11MB3558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
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: MIhvj9f32qtyk2P2hFNHnUA2xCaLjI07m9AHXlLc0RY6m3Pwxxp0PJlmqiL7k5It62cb6HiHjsTrHZgFBF4kmiWyebgdUMGGKJj4gMT+FtgzND+uExi2SYiP+sFKReOk6/5Xi/HRrHceQAJfQyewAGkpUCfNM34uOxYeaBr9NwzAWgB8JM03aGZiC+RQi0XKQUc0ktpQ0pfWG2gR42EbgN1S95b8fHuoRS2LWD5ctXFk93deGuGXjvd0b0TTu6cgCeX7biwxGa1tOLTWS2hGLVVB0Fv7gtmtmKDuy/GU86MbpBs96prkDbVbBRnU4Ucgx/a0V0kdtSuBWuwIPQt4UgnorLSS+tRg8nJ02GBVQ36CiT9T7O5FYav/R1QI5LvpPw/R0/BEka0u4L+6EWe+lkczYlOQaWmK5i8lbYInFWB/fwKbfA5ukjB6b3fvF9F51bYRK9n32BD9C5GqFXAq5e2yilrRxL4+4ZszE4h6Fk0YW/T0B7BRgvRc9cbFyGIcCllJMyjQFAU60k3XxHX9CFFIDu8J+X+YX1hg8V+Am3Q=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_1B030D749ABE48819B5055E67AC0784Fciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: be529439-329b-464d-8015-08d77aa0079e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 23:00:03.4909 (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: DDkQAJ0n8AsM0oTKwinsnbnFGrotg/19YAIF420427kwK5TkafScNANNsqs+9mmRBk3JFlebpC+FoScJBH73yg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3687
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/DPopsJl8MGQbME5EY47bSyz270w>
Subject: Re: [6tisch] MSF Shepherd review
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, 06 Dec 2019 23:00:41 -0000

Very good Tengfei

This addresses my comments.

Note that the uppercase NOT is not a valid BCP14 term by itself. I’d reword to say that the distribution of traffic over multiple parents is a routing decision that is out of scope for MSF...


Regards,

Pascal

Le 6 déc. 2019 à 12:01, Tengfei Chang <tengfei.chang@gmail.com> a écrit :


I will add the following text at the intro part of MSF draft:

                MSF works closely with RPL, specifically the routing parent defined in <xref target="RFC6550" format="default"/>.
                This specification only describes how MSF works with one routing parent, which is phrased as "selected parent".
                The activity of MSF towards to single routing parent is called as a "MSF session".
                Though the performance of MSF is evaluated only when the "selected parent" represents node's preferred parent, there should be no restrictions to go multiple MSF sessions, one per parent.
                In case that traffic goes into multiple parents, MSF is NOT in charge of deciding how many traffic to assign or to which parent.
                This should be decided by either upper layer or some other entity in charge of traffic distributing.

Then replace the sentence in the draft from "preferred parent" to "selected parent".

What are your comments on this, Pascal, Yatch?

On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
Hello Yatch



> Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr<mailto:yasuyuki.tanaka@inria.fr>> a écrit :
>
> Thank you, Pascal for your comment.
>
>> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
>> RPL underneath is designed to operate with multiple parents, and for a good reason.
>
> I understand that point.
>
> My point is, rephrasing the word alone couldn't be enough.
>
>> Bandwidth allocation doesn’t care what traffic that is or it’s direction. It cares about the amount of traffic that needs to circulate over the hop.
>
> In general, yes. According to the current text of MSF, the direction is relevant. For a upward neighbor, MSF allocates one negotiated TX cell just after recognizing it. For a downward neighbor, it doesn't.
>
> On parent switch, the number of negotiated cells is carried over to a new parent. But what if a node has one parents at some point, then it selects an additional parent to handle some portion of traffic? How many negotiated cells should be scheduled with the new (additional) parent? MSF would have no idea.
>
> To me, this seems a totally new thing to MSF.
>

Not that new just the logical continuation.

If a child has 2 parents a and b these are independent links, each with a number of cells. If it loses one parent a then the traffic on that link is rerouted. The cells on that link have to be moved to other parents which can include b.

The existing cells to the parent b are not touched. If some traffic is rerouted to parent b then new cells are allocated there.


> Again, having multiple MSF instances could be a solution, which doesn't need the rephrasing.

For me instance is related to RPL I do not want to run multiple instances of RPL with one preferred parent each.

What I want is to run what the draft describes but several times in parallel once per active parent.

That’s what I called session. RPL says that a node can run separate instances like ship in the night and then describes the operw of one instance. Similarly MSF can run multiple sessions one per link as ship in the night. pretty much the draft needs to do is say that in introduction and then say that the rest of the draft describes one session with one parent.

>> And it is possible to run an MSF session at L2 with each of them totally independently.
>
> What do you mean by "MSF session"? If you have multiple MSF instances with different SFIDs or values for the Metadata field, they can be associated with different RPL DODAGsm and they will work independently.
>

The draft describes a session between a parent and a child. They start the session, allocate resources in unison and when the session is broken they release the resources on each side. This happens within a L2 link. Sessions can live independently on different L2 links.



> On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> > Would it be then a neighbour instead of a parent? (Assuming the
> > neighbour has joined the network)
>
> I don't think so.
>

As Yatch said the draft describes a child handling both sides so the link is directional, there’s a master and a slave.

This may become a problem for east west traffic with PDAO. But there’s still a direction so it’s doable just need to agree that the parent is towards the destination.

All the best,

Pascal


> Best,
> Yatch
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org<mailto:6tisch@ietf.org>
> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org<mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch


--
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/<http://www.tchang.org/>
——————————————————————————————————————