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

[Tero Kivinen <[e-mail]>]

Thomas Watteyne writes:
> 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.

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

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

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.
-- 
[e-mail]