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