Re: [6tisch] MSF Shepherd review

Tengfei Chang <tengfei.chang@gmail.com> Fri, 06 December 2019 20:00 UTC

Return-Path: <tengfei.chang@gmail.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 C25B412013D for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 12:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ACfhGHyfACFn for <6tisch@ietfa.amsl.com>; Fri, 6 Dec 2019 12:00:37 -0800 (PST)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D7E120813 for <6tisch@ietf.org>; Fri, 6 Dec 2019 12:00:34 -0800 (PST)
Received: by mail-pj1-x1033.google.com with SMTP id ep17so3181122pjb.4 for <6tisch@ietf.org>; Fri, 06 Dec 2019 12:00:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q1UOliU03eC4CrQqMMjbLjJRyS7yAoylz2FSMrxWBqg=; b=M1WKZiSfVyiQUhSTlIGoZ65CX2CZOt70sZ1Bo0V2+xkd+u8smLwzvIC8mG9XM3V6j0 zjz2oeleTuSfvRmNKO7DNNEw8EzaDzf3v3qVE33YwN5w17jSjcbrAIczxOgpVe7z3e/p NYzY7RyH5RzhM7xET4ZCFT9QVriA7wGTnDpVTm8v/htdVfUPcGczNkzhmTUCcc5+UV60 9LJq6ZGZ9xQ4DSqLRc/8sYK2HQly45fFvkuAU/Lqz1lxBwUoN4lZCm+1w07cHTDEn8Jo llPQe2dQEc0ugQFciq42phpCyc9Xk0utX8CR/QQaRVSZS0w0RhcK7+FQvEM1TT54+Vtf xkDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q1UOliU03eC4CrQqMMjbLjJRyS7yAoylz2FSMrxWBqg=; b=M1j9bO2CEyebnhS8jeAORTdfESWkgwa7/A0vdjaiIM2k06RH5hoChuPM+dpWSM18Eg IRO2WxKFLJXUYrUTFQVaZC2geDUJPaZ0looG4ZSAtoP6rJ72ZsYG4Z0IHBrkO//5bTXp lX9XM/R+oQ0YXt72V2XKuSi2zcze0J7ie2jLesUZTU8I1SbQQPY8PGIu6Q1RyYFyUgsN 7OIWXe2n7vtjCMpD6WggjEKia0CjDWmoY1H4ZyAhqXAOhvoNNSYfFbEA5Clzewl8lneb JyXkfgjHyblTPrCSzBH3npWbQape8QU61T/oD/YzhXUygXTnKZFBbNOLuzRSXHjTwTbr ZQXQ==
X-Gm-Message-State: APjAAAWSojWkMeSgen2UfPQxxWjwFEC6BYWVw1Rakhxs3BYdGE0Soywi 1YHzzRIDxjlyL2MDC35qayvj5kUw2AtmD5kxEPPpct/xS0A=
X-Google-Smtp-Source: APXvYqydF5I5MCjC7OAfsJVRLo3bq7XKFUl1UCvk27gQFzs0fvomIYuXokDUCm+dsUiZI/FivO8IbO5fAEZpxp8qzPY=
X-Received: by 2002:a17:902:6b:: with SMTP id 98mr16897309pla.128.1575662434271; Fri, 06 Dec 2019 12:00:34 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <C2217F07-2C7E-4DB4-80E3-7AD6A9136DAA@cisco.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Fri, 6 Dec 2019 21:00:22 +0100
Message-ID: <CAAdgstRCbjt9-g3JA_9Yc1_o+rgu1bCj8=fpY9dUWG+ZPKNnEA@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>, "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ae471605990e7fe2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/ETTMbGh_D48ZNaVghq7BuKCKtH4>
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 20:00:42 -0000

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> wrote:

> Hello Yatch
>
>
>
> > Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka <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
> > https://www.ietf.org/mailman/listinfo/6tisch
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————