<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 <[email protected]> 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 < > [email protected]> 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 > [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 _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
