Re: [6tisch] follow up LIST cmd 6P

[Thomas Watteyne <[e-mail]>]

<chair hat off>
Same question here.
And frankly I fail to understand what the problem is we are trying to fix.
In today's text:
- if I receive less cells than I asked for, that means "end of list".
- if I ask for more cells that fit in the packet, I receive a "no
resources" error. I can then try again, asking for a smaller number of cells
That seams to work, no?
So what is the problem we are trying to solve again?

On Wed, Sep 7, 2016 at 10:26 PM, Qin Wang <[e-mail]> wrote:

> Hi Xavi,
>
> I think there are two scenarios which may result in the number of cells in
> the CellList of response packet less than numCells_max,
> (1)  when node B has N cells, where Offset<N and N<Offset+numCells_max
> cells;
> (2) when node B has more than Offset+numCells_max cells, but numCells_max
> cells cannot be fitted in the packet.
>
> My question is how to distinguish one from another from node A side? Did I
> miss something?
>
> Thanks
> Qin
>
>
> On Tuesday, September 6, 2016 4:45 AM, Xavier Vilajosana <
> [e-mail]> wrote:
>
>
> Hi,
>
> according to our discussion during the last 6TiSCH meeting I want to
> follow up Tero's proposal for the LIST cmd.
>
> here you will find his initial proposal
> https://www.ietf.org/mail-archive/web/6tisch/current/msg04719.html
>
> As a summary, the proposal enables 6P list to return a best effort set of
> cells, this is as many as can be fitted in a packet below a maximum. This
> makes the list command robust to the presence of other IEs in the packet
> (which sometimes may be present and some times don't and hence would make
> two identical requests to succeed or fail. With this approach LIST is
> independent of the remaining space in the packet)
>
> I follow up the discussion by proposing these changes to 6P.
>
> 1- change numCells field to numCells_max as follow:
>
>                         1                   2
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |Version|  Code |    SFID       | SeqNum|GAB|GBA|   Metadata
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          Metadata    |            Offset             |   numCells_max
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                      |
>      +-+-+-+-+-+-+-+-+
>
> where
>
> numCells_max:  The maximum number of requested cells.  Less cells
>          than numCells_max can be returned if they do not fit in the
>          packet.
>
> Then I propose the following text
>
> 4.3.10.  Listing Cells
>
>    When a node A issues a LIST_AB or LIST_BA command, it specifies:
>
>    o  Through the "Offset" field, the offset of the first cell to be
>       present in the returned list.  The cell ordering policy is defined
>       by the SF.
>    o  Through the "numCells_max" field, the maximum number of cells to
>       be present in the reponse.  If numCells_max cannot be fitted in the
>       packet less cells will be returned.
>
>    When receiving a LIST_AB command, node B returns the cells that are
>    scheduled from A to B in its schedule (i.e. receive cells from node
>    A).  When receiving a LIST_BA command, node B returns the cells that
>    are scheduled from B to A in its schedule (i.e. transmit cells to
>    node A).  The RECOMMENDED format of each 6P Cell is defined in
>    Section 4.2.5.  The SF MAY redefine the format of the CellList field.
>
>    Depending on how many cells node B has in its schedule which match the
>    LIST_AB or LIST_BA request, the cellList returned in the 6P Response
>    contains between 0 and numCells_max cells:
>
>    o  If node B has more than Offset+numCells cells, the cellList it
>       returns contains exactly numCells cells as long as the cellList
>       fits in the packet.  Otherwise it returns a cellList containing
>       the maximum number of cells that fit in the packet.
>    o  If node B has N cells, where Offset<N and N<Offset+numCells_max
>       cells, the cellList it returns contains exactly N-Offset cells.
>       If that number of cells do not fit in the packet, the cellList
>       containing the maximum number of cells that fit in the packet is
>       returned.
>    o  If node B has less than Offset cells, the cellList it returns is
>       empty.
>
>
> Please, raise any pros and cons you may find in this approach.
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> 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
_______________________________________