Absolutely. I can take the lead on this. On Fri, Sep 22, 2017 at 1:41 PM, Pascal Thubert (pthubert) < [email protected]> wrote:
> Could we take 5 minutes to discuss this at the interim? We need to close > the issue… > > > > *From:* 6tisch [mailto:[email protected]] *On Behalf Of *Thomas > Watteyne > *Sent:* vendredi 22 septembre 2017 13:33 > *To:* Liubing (Remy) <[email protected]> > *Cc:* [email protected]; Xavi Vilajosana Guillen <[email protected]> > > *Subject:* Re: [6tisch] Question about the Relocation in 6P > > > > Remy, Qin, all, > > > > I'd like to make sure we don't overdesign here. > > > > The RELOCATE command, as defined now, considers that all cells to be > relocated are equivalent: they have the CellOptions, and are part of the > same bundle. If the first cell cannot be relocated, the second cannot > either. What is in the text is perfectly suitable for that use case. > > > > I'm not at all convinced about the use case you are discussing here. If > there are 2 logical groups of cells, and different restrictions on the > candidate cells for each, then you just issue 2 independent RELOCATE > commands. Let's not cram additional features into this, it's already > complex enough. > > > > If there is a very compelling counter-example, in a very specific > application case, then it's completely possible to redefine the format of > the RELOCATION messages in the SF, as specified in the text. > > > > Thomas > > > > On Tue, Sep 12, 2017 at 3:30 AM, Liubing (Remy) <[email protected]> > wrote: > > Hi Qin, > > Thank you for your summary. > > I prefer option (2) for two reasons. > > Firstly, there are two CellLists in the Request message (one of them is > optional), thus it is logical to have two CellLists in the Response > message. If the relocation verification fails, the second CellList is > elided. > > Secondly, if the option (1) is used, the size of the CellList is always > the same as the R.CellList in the Request message, therefore the relocation > failure is identified by a CellList of (NaN,NaN) cells; if the option (2) > is used, the failure is identified by an empty CellList, which maintains > the consistency of design philosophy with ADD and DELETE. > > Best regards, > Remy > > > From: Qin Wang [mailto:[email protected]] > Sent: Tuesday, September 12, 2017 4:37 AM > To: Liubing (Remy) <[email protected]>; Xavi Vilajosana Guillen < > [email protected]> > > Cc: [email protected] > Subject: Re: [6tisch] Question about the Relocation in 6P > > Hi Remy, Xavi and all, > > Per the WG meeting on last Friday, we are going to solve the Relocation > issue before publishing new version of 6P draft. I put previous discussion > on the issue into three options as follows . Can we make choice from the > following options? > > (1) Introduce (NaN,NaN) as a cell value, change the definition of CellList > in the Response message, i.e. a list of new locations for all of the cells > which are required to be relocated. The cell value could be a cell in the > Candidate CellList in the Request message, or (NaN, NaN). > > (2) Two CellLists in the Response message. The first one indicates the > cells which can be relocated, and the second one indicates the related new > cells. If the number of elements in the first CellList is 0, it means the > relocation fails. > > (3) Keep what is in the current version > > Personally, I prefer (1). What do you think? > > Thanks > Qin > > > > On Thursday, September 7, 2017 3:50 AM, Liubing (Remy) < > [email protected]> wrote: > > Hi Qin and Xavi, > > Yes, that is what I meant. Thank you for your example. In this case, the > CellList in the response message will be the same size as the R.CellList. > This idea may bring more flexibility for the relocation SFs designed in the > future. Now I have another idea below. > > The current solution in 6P for ADD, DELETE, and RELOCATE maintains good > consistency in the design of the response message, i.e. the three > possibilities of the verification: succeed, fail, and partially succeed. > The three possibilities have the same return code set to SUCCESS, and are > distinguished by the number of the elements in the message. However, the > logic of RELOCATE seems to be more complicated compared to ADD and DELETE, > because there are two CellLists in the RELOCATE require message which > should have more possibilities. > > That is why I was thinking of introducing an empty cell (NaN, NaN) to > indicate a relocation failure of a specific cell. But it seems to be > inefficient to identify the result of the SF’s verification, because the > CellList in the response message will be the same size as the R.CellList in > the require message. And the complete relocation failure will be identified > by a CellList of empty cells. In order to do it more efficiently, the > return code can be changed to “FAILURE”, but it will break the consistency > with ADD and DELETE. > > I have another idea here: it can also have two CellLists in the response > message. The first one indicates the cells which can be relocated, and the > second one indicates the related new cells. If the number of elements in > the first CellList is 0, it means the relocation fails. And in this case, > the second CellList can be elided. In case of succeed and partially > succeed, the second CellList is mandatory. This idea can maintain the > consistency with ADD and DELETE. > > Which one do you think is better? Using the empty cell or using two > CellLists in the response message? > > Best regards, > > Remy > From: Qin Wang [mailto:[email protected]] > Sent: Thursday, September 07, 2017 3:39 AM > To: Liubing (Remy); Xavi Vilajosana Guillen > Cc: [email protected] > Subject: Re: [6tisch] Question about the Relocation in 6P > > Hi Ramy, > > I can see your point. I think, as you proposed, a list of relocated cells > in Response message may be a good idea, because it supports more > flexibility. Take Fig 15 as an example. Assume only (4,2) is available at > nodeB. If (1,2) is relocated to (4,2), then, the list of relocated cells in > Response message is [(4,2), (NaN, NaN)], otherwise [(NaN, NaN), (4,2)]. > Right? > > BTW, it is impossible for (1,2) and (2,2) to be of different type (Rx and > Tx) as you suggested, because all of the cells in both relocation list and > candidate list are under one CellOptions. > > Thanks > Qin > > On Monday, September 4, 2017 3:16 AM, Liubing (Remy) < > [email protected]> wrote: > > Hi Xavi, > > Thank you for your response. > > I think the cells are equivalent if they belong to the same bundle. For > example, the cells (1,2) and (2,2) are used together to transmit a > relatively large packet. In this case, the two cells should be considered > as a whole: if (1,2) cannot be relocated then (2,2) won't be able too; > otherwise, if (1,2) can be relocated and (2,2) can't, it might be > inappropriate to relocate (1,2) only, because it could cause packet loss. > > If (1,2) and (2,2) are of different purpose (to transmit different > packets) or of different type (RX and TX), they can be considered > independently: the relocation of (2,2) should be considered even if the > relocation of (1,2) fails. > > Indeed, the policy is implementation-specific, but it might be better for > 6top to support more possibilities. For example, a cell (NaN, NaN) could be > used to represent a relocation failure. > > Best regards, > > Remy > > From: Xavi Vilajosana Guillen [mailto:[email protected]] > Sent: Friday, September 01, 2017 5:18 PM > To: Liubing (Remy) > Cc: [email protected] > Subject: Re: [6tisch] Question about the Relocation in 6P > > Hi Remy, > > I think this can be an implementation decision. IMHO, when a node requests > a relocation like the one in Figure 15, it assumes that any of the > candidate cells is equivalent. This means that if [1,2] cannot be relocated > then [2,2] won't be able too. Seen in another way, the relocation may > happen in the list order consuming all possible candidate cells. This can > be seen as a policy that may depend on the implementation or SF rules so > other options may also be possible but are out of the scope of 6P.. > > Do you have a specific example where the case you present is relevant? > > regards, > Xavi > > 2017-08-30 8:29 GMT+02:00 Liubing (Remy) <[email protected]>: > Hello folks, > > I have a question about the relocation of cells in the draft > 6tisch-6top-protocol. > > In section 4.3.3, node A wants to relocate several cells and selects > candidate cells from its schedule for node B, then node B's SF verifies > which of the cells it can install in its schedule. The verification can be > partially succeed. If N < NumCells cells appear in the CellList, this means > first N cells in the Relocation CellList have been relocated, the remainder > have not. > > Does this mean that if the relocation of the first cells fails, there > would not be necessary to verify if the rest cells could be relocated? For > example, in Figure 15, if the cell (1,2) in the R. CellList cannot be > relocated to any of the cells in C.CellList, then (2,2) will not be > relocated even if it is possible to relocate it to (6,5)? > > Thanks, > > Remy > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > Internet Interdisciplinary Institute (IN3) > Professor > (+34) 646 633 681 > [email protected] > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+%0D+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g> > 08860 Castelldefels (Barcelona). Catalonia. Spain > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > -- > > _______________________________________ > > > > Thomas Watteyne, PhD > > Research Scientist & Innovator, Inria > > Sr Networking Design Eng, Linear Tech > > Founder & co-lead, UC Berkeley OpenWSN > > Co-chair, IETF 6TiSCH > > > > www.thomaswatteyne.com > > _______________________________________ > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
