Subject: [6tisch] follow up LIST cmd 6P

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 6 Sep 2016 10:36:14 +0200

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.

---

From: Qin Wang <[email-masked]>
Date: Wed, 7 Sep 2016 20:26:37 +0000 (UTC)

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?
ThanksQin 

    On Tuesday, September 6, 2016 4:45 AM, Xavier Vilajosana <[email-masked]> 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 proposalhttps://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-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 7 Sep 2016 23:27:42 +0200

<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-masked]> 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.
>
> Thanks
> Qin
> according to our discussion during the last 6TiSCH meeting I want to
> follow up Tero's proposal for the LIST cmd.
>

-- 
_______________________________________

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
_______________________________________

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 8 Sep 2016 12:23:27 +0200

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-masked]>:

>> I think there are two scenarios which may result in the number of cells
>> in the CellList of response packet less than numCells_max,

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Sep 2016 14:49:53 +0300

> - 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?

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-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 8 Sep 2016 13:58:31 +0200

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-masked]> wrote:

> resources"
> [email-masked] <javascript:;>
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Sep 2016 15:46:57 +0300

> there is no space at all, even for a single cell.

If we have that many other IEs, then we do have other issues too. I
mean, the examples we have given are using really tiny frames,
something like 30 octets. The default frame size is 127, so I do not
really expect it to lower the number of cells down to 4, but closer to
20... 

> 15.4-2015 that explains the rules for piggybacking?

Nope. All of that is left for upper layers to decide. IEEE
specifications just define the IEs, and how they are encoded, and in
latest version it also includes in which frame types they are
typically used, but when to send them is mostly left for
implementations to decide.

In some cases it do say that certain IEs shall be piggybacked, like
Time Correction IE and Link Margin IE (from 802.15.4q). Those both are
in Enhanced ACKs so they are not an issue here, but for example the
802.15.10 (mesh networking) will put some routing etc IEs on all
frames. Fortunately it is most likely not used with 6tisch.

Anyways mostly this is just in case someone adds more and more IEs
that do things on frames. Currently there is not that many that are
added in the data frames, or at least there is no defined use for
them...

This issue is much bigger on the Enhanced Beacons, as there is so many
different IEs you can put there.
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 9 Sep 2016 22:21:47 +0200

Tero,

Thanks for the explanation.

I looks like a single sentence in the 6P draft banning piggybacking
non-6P IEs would make the problem disappear, no?

Thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com