Subject: [6tisch] (no subject)

From: Tengfei Chang <[email-masked]>
Date: Mon, 12 Dec 2016 17:18:33 +0100

Hi Yatch, Prof. Qin

Thanks for your comments! Let's me explain my thought more further.

The important benefit is the two cell list 6top format could support
scheduling function better on bandwidth estimation.

An important thought behind this idea is we don't treat Relocation as a
policy in SF0 but a decision SF0 can use during estimating  bandwidth
requirement, like ADD, DELETE command.

With this thought, the SF0 may end up with a decision with:

   1. Relocating cell 1 and 2 to cell 3 and 4,
   2. and Add one more cell 5.

*(1,2,3,4,5 are the slotoffset of cells, just for simplification)*

With the proposed format, the adding list will be [3,4,5] and deleting list
will be [1,2]. If we want to give more choice on choosing which one to
allocate, the adding list can be  like [3,4,5,6,7] and finally pick up 3
out of them. It's the same if the decision is relocating some cell +
deleting.

With this format:

   1. SF0 could manage the schedule/bandwidth more flexible, by taking the
   affect after relocation into account.
   2. as the finally decision can be archived with single 6top transaction
   instead of two, the 6top traffic could be reduced.

Regard,
Tengfe

On Mon, Dec 12, 2016 at 4:32 PM, Qin Wang <[email-masked]> wrote:

> Hi Tengfei,
>
> My impression on your proposal is that you are trying to use the
> combination of the length of ADD CellList and DELETE CellList as sort of
> operation code. Right? If 6P really needs so many operations, why do we
> just add more operation codes, which could cost just 1 more bit?
>
> Thanks
> Qin
>
>
> On Friday, December 9, 2016 10:53 AM, Tengfei Chang <
> [email-masked]> wrote:
>
>
> Dear all,
>
> As we are going to have RELOCATE command in sixtop draft, then we will
> need add a specific format for RELOCATE. Though the format is not discussed
> yet, but I think finally it will ends up something with two list of cell in
> the packet and having (a) fields to indicate where the cell list to be
> added and list to be removed are. Of course , with RELOCATE command byte in
> the frame. I think this format can be a general format for ADD , DELETE
>  and RELOCATE.
>
> With such format,
>
>    - if there is only list of cell to be added, then the frame can be
>    represented as ADD command
>    - if there is only list of cell to be removed, then DELETE  command
>    - if there are both two list of cell, and they have the same number,
>    then RELOCATE command..
>
> The benefit of using this two cell list format is that:
>
> If the node wants to relocate one cell and at the same time add some cells
> OR delete some cells, with single sixtop transaction, which is
>
>    - there are two list of cell, one for adding, one for deleting, but
>    length of adding list is longer than deleting list (Add command+Relocation
>    command)
>    - there are two list of cell, one for adding, one for deleting, but
>    length of adding list is shorter than deleting list (Delete
>    command+Relocation command)
>
> Let me know your thought.
>
> Tengfei
>
> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer, Inria
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria