Xavier Vilajosana writes:
> that is why we use pagination. Assume the command LIST_AB issued by node A to
> node B. Assume B has 10 cells in its schedule being
> (1,3,5,7,9,11,13,15,17,19), assume also that a packet can only transport 4
> cells.
>
> Node A can issue STATUS to Node B. B will respond ti has 10 cells.
> then
> Node A will issue
> LIST_AB offset=0 num cells=4
> Node B will respond
> 1,3,5,7
>
> Node A then will issue
> LIST_AB offset=4 num cells=4
> Node B will respond
> 9,11,13,15
>
> Node A then will issue
> LIST_AB offset=8 num cells=2
> Node B will respond
> 17,19
>
Ah missed the status command, so other end has already way of telling
the number of cells, so why does the Node B need to respond with full
list of frame every time? Wouldn't it be better to allow Node B return
as many frame it can starting from offset:
Node A issue STATUS -> Node B replies with 10
Node A issues LIST_AB offset=0, num_cells_max=4 ->
Node B respondes 1, 3, 5, 7
Node A issues LIST_AB offset=4, num_cells_max=4 ->
Node B respondes 9, 11, 13 (+ some other IEs which consumed space
from frame, so there was no space for 4 cells)
Node A issues LIST_AB offset=7, num_cells_max=4 ->
Node B respondes 15, 17, 19
I.e. the num cells would just limit the number of cells other end can
respond, but other end can also sent less if it does not have space
for them in the frame (or if for some other reason it thinks it it is
better to send them in smaller chunks).
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
