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 protected]> 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 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
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
