Re: [6tisch] MSF Shepherd review

Tengfei Chang <tengfei.chang@gmail.com> Sat, 07 December 2019 11:49 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 B905012021C for <6tisch@ietfa.amsl.com>; Sat, 7 Dec 2019 03:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 0-x_EEB2K-We for <6tisch@ietfa.amsl.com>; Sat, 7 Dec 2019 03:49:12 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 E01A2120219 for <6tisch@ietf.org>; Sat, 7 Dec 2019 03:49:11 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id b9so4292185pgk.12 for <6tisch@ietf.org>; Sat, 07 Dec 2019 03:49:11 -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=ehdlJYvyYB7cf5jv4nsth8Yr67QdAw3fOs837ByvBk0=; b=iLnZ5XlKTb66U7KqhCEo4n5kVgBsRg5dUbfm+08KXk7VD+TOUXCWizli51GGJkBzIG qrNeqEARnfkP3S42GdHvUzT9O0/Uea1M+Oq8SbDUS5sqMTV40mRbtf6eLrBoo5hi14Li VIfhMJYLSoyQ5fRfQIhWz+pd0dyB6ov1LPUMb1susk+9Rk+lvxk5iktg97/7214Kfsub aBuc6vVrOJ70GyHm73w0jLuT/RlJqQi4Eoyd38GV9afUyauJTNYWV6mibc2PQ2/5M2HD cMa2end9lkww1H/65hFup5C2ZPoAflraK17p5SHAOF2umqlkis214U0E1idK72sGvyYL k7KQ==
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=ehdlJYvyYB7cf5jv4nsth8Yr67QdAw3fOs837ByvBk0=; b=ZicHDWgQfpAcK/tcokmx7Sm9+MvOua1hkciXf13fm/fMfQFt58QcOPAItydm2uPBz+ 39n7q2bdSDL59DGLT0nh3MqN+sUa4xY7+SsQ8aTUesguQrQX608YR9ugQjGaShlzeFbJ pFLsUZ3FFVmclC3AmaxVr1feD7AesaPeLc0qUJYHe/hTv2c45S+jMBUGbx2CTwXUD62t Cp0UrJvE3XQp/gXIwqDsZJdPHwLdaAVgBhhbFl+6skycLwc798TNY6P7nb4Sso5RaFrG 7ZHwsA1DZcOFppziPZnmVaAOauaCytXojH+LrvYLCp9fE8YIFn8+wK5MAXmVQH+Hppv8 Bpng==
X-Gm-Message-State: APjAAAX7C4YseV78iL8hoc7RdMv8yYcrDBwPWMH2XX+g1To07r3xK2JK h3sIhnelVcwjfrI1rARB9DxNX+/NwIob0zmB6vU=
X-Google-Smtp-Source: APXvYqyTpM3/nUdJmHDxQz8f9Z+Gnu/GaPe7d4J8ZjISHOXn/EBKMihSncBnWBjndvcmkke8Ped+Peau4ATnA2aCQPE=
X-Received: by 2002:a63:4a50:: with SMTP id j16mr8967704pgl.308.1575719351223; Sat, 07 Dec 2019 03:49:11 -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> <CAAdgstRCbjt9-g3JA_9Yc1_o+rgu1bCj8=fpY9dUWG+ZPKNnEA@mail.gmail.com> <1B030D74-9ABE-4881-9B50-55E67AC0784F@cisco.com>
In-Reply-To: <1B030D74-9ABE-4881-9B50-55E67AC0784F@cisco.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Sat, 7 Dec 2019 12:48:58 +0100
Message-ID: <CAAdgstQV2KENAfw2PEPsmMMJO__pEckUrGRV3meM25iWuzWkDQ@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="000000000000320a4705991bc0cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/vebG2oekkkT0GdoXMP_1Ls7j0u8>
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: Sat, 07 Dec 2019 11:49:15 -0000

Thanks Pascal, just integrated your suggestions to the latest version.

On Sat, Dec 7, 2019 at 12:00 AM Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> 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> 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/
> ——————————————————————————————————————
>
>

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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

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