Hi Thomas, Qin yes the approach now works. The problem I see is the following:
Consider a FOO IE that can be in the packet or not and it is not dependent to 6P. When a node issues a LIST indicating the offset and the elements to receive the success of the command is tighten to whether the FOO IE is present or not in the response packet. This can cause two identical queries one to succeed and the other to fail, for me this is not a good design. According to Tero's position and I kind of agree it seems more robust to make the 6P LIST command use all the remaining space in the packet (up to the specified limit), despite of other IEs or headers. As a node may know how many cells there are in the schedule using the STATUS cmd a node can know when it has received all of them. In summary, the CONS I see in the present mechanism are: - requires certain back and forth to calibrate the size to paginate optimally - subsequent identical queries may have different responses (despite of the previous calibration). The risk is to paginate with pages that do not use the entire remaining space in the packet. the PROS I see of the proposed method: -it is best effort returning as much cells as can be fitted in the packet. No other "calibration" is required. -Empty means no space in the current packet. the CONS I see is that we require some little state to keep track of how many cells we have already retrieved and requires a STATUS cmd before the list sequence in case that all cells want to be obtained. As per Qin question, I think that it does not matter to differentiate both cases, in both of them we will receive less than the max cells requested (is the upper bound). As we know the number of cells in the schedule (through the status command) we know when to stop querying. happy to discuss further, note that I want to find the simplest approach that works well :) so you can still convince me. regards, Xavi 2016-09-07 23:27 GMT+02:00 Thomas Watteyne <[email protected]>: > <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 > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
