Tero, I agree no functionality is lost if the mote must return at least one cell. But it's a race condition: what happens if there are so many other IEs that there is no space at all, even for a single cell. And while I am not doubting that many more IEs will be invented for many different things, I'm skeptical when you explain that all of these will happily be piggybacked in 6P messages. Surely there must be a sentence in 15.4-2015 that explains the rules for piggybacking? Thomas
On Thursday, September 8, 2016, Tero Kivinen <[email protected]> wrote: > Thomas Watteyne writes: > > 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". > > You get information how many cells there are by doing status request > first. I.e. you do STATUS request and get STATUS response back saying > there 10 cells from A to B, and 5 to B to A. > > Then you do LIST_AB request with offset = 0, numCells = 4. Now, the > other end is supposed to send you exaclty first 4 cells. If it cannot > then it returns error. The issue with error is that forces the other > end to remake the request with smaller number of numCells, and if this > was just caused by some IE to be added to response this will create > extra traffic. With new approach it will just return 3 cells, and > there is no wasted frames because of someone added IEs to response. > > Also you do not need to do STATUS command even in this scenario, as > if you ask cells starting from offset, which is bigger than the number > of cells, you get empty list, which will signal that there is no more > cells. I think we need to define that in other cases you need to > return at least one cell, i.e., only case where you are allowed to > send zero cells is when you are end of list. > > So currently the process works like this: > > Node A Node B > STATUS -> > <- A->B 10, B->A 5 > LIST_AB o=0,nc=4 -> > <- 4 cells > LIST_AB o=4,nc=4 -> > <- responder cannot return 4 cells, as > there is other stuff to be returned > too, it returns error > RC_ERR_NORES (no cells) > LIST_AB o=4,nc=3 -> > sender lowers nc <- responder still cannot return that > many cells, and returns error again > RC_ERR_NORES (no cells) > LIST_AB o=4,nc=2 -> > sender lower nc again <- 2 cells (+ other stuff making > frame big) > LIST_AB o=6,nc=2 -> > sender keeps low nc <- 2 cells (and no other stuff, so > could have returned 4 cells) > LIST_AB o=8,nc=2 -> > <- 2 cells > As A did STATUS he now > knows he have everything. > If he did not do the STATUS > he will do next request > LIST_AB o=10,nc=2 -> > <- 0 cells indicating end of list. > > Of course the Node A could also raise nc back to 4 when it gets the > reply back, but that would cause it to send more frames in those cases > where there is always some extra stuff in frame. > > With new proposed version: > > > Node A Node B > STATUS -> > <- A->B 10, B->A 5 > LIST_AB o=0,nc=4 -> > <- 4 cells > LIST_AB o=4,nc=4 -> > <- responder cannot return 4 cells, as > there is other stuff to be returned > too, it returns only 2 > 2 cells (+ other stuff) > LIST_AB o=6,nc=4 -> > <- 4 cells (there is no other stuff > to send, so can fit 4) > LIST_AB o=10,nc=4 -> > <- 0 cells indicating end of list. > > Of course if the Node A did the STATUS request, he could leave the > last request out, as he knows he already have everything as there is > only 10 cells. > > > - 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? > > With more and more features in 802.15.4 there will most likely be > other management kind of IEs added to the frames. This will make it so > that maximum usable frame size changes over time depending what kind > of IEs are included to the frames. The new version is more flexible > with that, and should be easier to implement, as there is no need to > do fallbacks to smaller numCells requests etc. > -- > [email protected] <javascript:;> > -- _______________________________________ 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
