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