Subject: Re: [6tisch] Question about the Relocation in 6P

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 1 Sep 2017 11:17:46 +0200

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-masked]>:

> 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-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: "Liubing (Remy)" <[email-masked]>
Date: Mon, 4 Sep 2017 07:16:37 +0000

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-masked]] 
Sent: Friday, September 01, 2017 5:18 PM
To: Liubing (Remy)
Cc: [email-masked]
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.. 

regards,
Xavi

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

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
[email-masked]
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia 
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: Qin Wang <[email-masked]>
Date: Wed, 6 Sep 2017 19:38:43 +0000 (UTC)

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

    On Monday, September 4, 2017 3:16 AM, Liubing (Remy) <[email-masked]> wrote:

 Hi Xavi,

Best regards,

Remy

Hi Remy,

regards,
Xavi

Thanks,

Remy

---

From: "Liubing (Remy)" <[email-masked]>
Date: Thu, 7 Sep 2017 07:50:20 +0000

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-masked]]
Sent: Thursday, September 07, 2017 3:39 AM
To: Liubing (Remy); Xavi Vilajosana Guillen
Cc: [email-masked]
Subject: Re: [6tisch] Question about the Relocation in 6P

Hi  Ramy,

Thanks
Qin

On Monday, September 4, 2017 3:16 AM, Liubing (Remy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Xavi,

Best regards,

Remy

From: Xavi Vilajosana Guillen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, September 01, 2017 5:18 PM
To: Liubing (Remy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Question about the Relocation in 6P

Hi Remy,

regards,
Xavi

2017-08-30 8:29 GMT+02:00 Liubing (Remy) <[email-masked]<mailto:[email-masked]>>:
Hello folks,

Thanks,

Remy

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

--
Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
[email-masked]<mailto:[email-masked]>
http://xvilajosana.org<http://xvilajosana.org/>
http://wine.rdi.uoc.edu<http://wine.rdi.uoc.edu/>
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Mon, 11 Sep 2017 20:37:14 +0000 (UTC)

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?
ThanksQin

    On Thursday, September 7, 2017 3:50 AM, Liubing (Remy) <[email-masked]> wrote:

 #yiv4230586916 #yiv4230586916 -- _filtered #yiv4230586916 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv4230586916 {font-family:宋体;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv4230586916 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv4230586916 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv4230586916 {panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv4230586916 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv4230586916 #yiv4230586916 p.yiv4230586916MsoNormal, #yiv4230586916 li.yiv4230586916MsoNormal, #yiv4230586916 div.yiv4230586916MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:宋体;}#yiv4230586916 a:link, #yiv4230586916 span.yiv4230586916MsoHyperlink {color:blue;text-decoration:underline;}#yiv4230586916 a:visited, #yiv4230586916 span.yiv4230586916MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv4230586916 span.yiv4230586916EmailStyle17 {color:#1F497D;}#yiv4230586916 .yiv4230586916MsoChpDefault {font-size:10.0pt;} _filtered #yiv4230586916 {margin:72.0pt 90.0pt 72.0pt 90.0pt;}#yiv4230586916 div.yiv4230586916WordSection1 {}#yiv4230586916 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-masked]]
Sent: Thursday, September 07, 2017 3:39 AM
To: Liubing (Remy); Xavi Vilajosana Guillen
Cc: [email-masked]
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-masked]> wrote:    Hi Xavi,

Best regards,

Remy 

Hi Remy,

regards,
Xavi

Thanks,

Remy

---

From: "Liubing (Remy)" <[email-masked]>
Date: Tue, 12 Sep 2017 01:30:33 +0000

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-masked]] 
Sent: Tuesday, September 12, 2017 4:37 AM
To: Liubing (Remy) <[email-masked]>; Xavi Vilajosana Guillen <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] Question about the Relocation in 6P

Hi Remy, Xavi and all,

Thanks
Qin

Hi Qin and Xavi,

 

 
Best regards,
 
Remy
 
Hi  Ramy,

 
Thanks
Qin

Hi Xavi,

Best regards,

Remy

Hi Remy,

regards,
Xavi

Thanks,

Remy

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 Sep 2017 13:32:57 +0200

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

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

-- 
_______________________________________

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
_______________________________________

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Sep 2017 11:41:11 +0000

Could we take 5 minutes to discuss this at the interim? We need to close the issue…

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: vendredi 22 septembre 2017 13:33
To: Liubing (Remy) <[email-masked]>
Cc: [email-masked]; Xavi Vilajosana Guillen <[email-masked]>
Subject: Re: [6tisch] Question about the Relocation in 6P

Remy, Qin, all,

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-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

Best regards,
Remy

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, September 12, 2017 4:37 AM
To: Liubing (Remy) <[email-masked]<mailto:[email-masked]>>; Xavi Vilajosana Guillen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Question about the Relocation in 6P

Hi Remy, Xavi and all,

Thanks
Qin

On Thursday, September 7, 2017 3:50 AM, Liubing (Remy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Qin and Xavi,

Best regards,

Remy
From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]

Hi  Ramy,

Thanks
Qin

Hi Xavi,

Best regards,

Remy

Hi Remy,

regards,
Xavi

Thanks,

Remy

(+34) 646 633 681<tel:%28%2B34%29%20646%20633%20681>

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 Sep 2017 15:03:02 +0200

Absolutely. I can take the lead on this.

On Fri, Sep 22, 2017 at 1:41 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Thomas
> Watteyne
> *Sent:* vendredi 22 septembre 2017 13:33
> *To:* Liubing (Remy) <[email-masked]>
> *Cc:* [email-masked]; Xavi Vilajosana Guillen <[email-masked]>
>
> *Subject:* Re: [6tisch] Question about the Relocation in 6P
>
>
>
> Remy, Qin, all,
>
>
>
> <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+%0D+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Liubing (Remy)" <[email-masked]>
Date: Sat, 23 Sep 2017 01:42:37 +0000

Hi Thomas,

Thank you for your explanation. It is a good design.

Best regards,

Remy

From: Thomas Watteyne [mailto:[email-masked]]
Sent: Friday, September 22, 2017 7:33 PM
To: Liubing (Remy) <[email-masked]>
Cc: Qin Wang <[email-masked]>; Xavi Vilajosana Guillen <[email-masked]>; [email-masked]
Subject: Re: [6tisch] Question about the Relocation in 6P

Remy, Qin, all,

Thomas

Best regards,
Remy

Hi Remy, Xavi and all,

Thanks
Qin

Hi Qin and Xavi,

Best regards,

Remy

Hi  Ramy,

Thanks
Qin

Hi Xavi,

Best regards,

Remy

Hi Remy,

regards,
Xavi

Thanks,

Remy

Thomas Watteyne, PhD