Hi Thiago, Thank you for your reply.
Regarding bandwidth and power consumption, I've never implemented a protocol in HW so you may be right that sending extra payload won't have an effect. We all come to this with our direct experience and our assumptions and often times we're wrong no matter how right we think we are. :) My ideas about this come from two sources. First, I've seen other protocols (BTLE, for example) that go to great lengths to reduce the message payload to make things more efficient from a bandwidth and power consumption point of view. I have no idea how much a difference that makes with respect to battery life, for example. Second, from a logical point of view, sending an extra 50 to 60 bytes seems like a lot (assumes that the different "if" messages are similar to what I suggested in my first email). Again, I have no idea how much that translates to with respect to power consumption but it will likely more than double the size of every message sent. With that said, if you have small-cell battery sensor that sends its temperature once every second, that's a whole lot of transmissions in one year and saving just a few uA on each transmission could add up to a lot. Regarding the fact that in the end, the Client dictates the interface used, I agree. But, many people who write client applications won't know that if the Default is oic.if.baseline, they could save power by adding an oic.if.s query to their request; otherwise the Server will be forced to operate in an less efficient way. If we don't agree on giving Servers the flexibility to set their own Default Interface based on the application, one solution, as I said before, is to make the Interface that uses the fewest number of bits as the Default Interface wherever possible to ensure that if Servers have to send "the whole package" it's because the Client explicitly asked for it. Mitch -----Original Message----- From: Thiago Macieira [mailto:[email protected]] Sent: Thursday, February 04, 2016 1:27 PM To: Mitch Kettrick Cc: 'Subramaniam, Ravi'; 'Maloor, Kishen'; oswg at openinterconnect.org; iotivity-dev at lists.iotivity.org Subject: Re: [oswg] Re: [dev] Default interface signaling On quinta-feira, 4 de fevereiro de 2016 11:26:09 PST Mitch Kettrick wrote: > Hi, > > Just to add a few points/clarifications to what Ravi has said: > > 1. From a test and certification standpoint, we will be verifying that > read-only Properties cannot be written/updated regardless of the > Interface used. In other words, even though oic.if.baseline supports > writing, you should not be able to update a read-only Property when > using it. This will be checked. Hello Mitch Thank you, this was implied but is of course good to have it stated explicitly. > 2. Think about a sensor that is asked to send it's temperature every > second. With oic.if.baseline, the message would looks something like: [cut] > Some clients may be smart enough to use an "if" query to request > oic.if.baseline the first time and oic.if.s for all subsequent messages. > But not all clients (or their developers) will think from a > constrained device perspective and will be perfectly happy to get the > full oic.if.baseline response every time and only filter out the > temperature value from the entire message. Not good from a battery life perspective. > Allowing the sensor vendor the ability to declare oic.if.s the Default > Interface at least forces Clients to specifically ask for more info > (using and "if" query for oic.if.baseline) rather than having that be > the de facto message format. Here I disagree with you. First, I disagree that sending a smaller packet will result in battery savings, if a transmission is to happen at all. I may be wrong on my details of how the transceivers work, but I doubt that sending a handful of bytes fewer will affect the consumption at all. So long as the baseline's response don't cause fragmentation and thus the need for multiple packets, the power consumption should be the same. Second, and this is my main point of contention in this discussion, the server's choice in default is meaningless. You said it yourself: "some clients may be smart enough to use an "if" query to request [...] oic.if.s for all subsequent messages". The relevant portion here is that the *client* makes the choice and the server's default was never factored into that decision-making process. So I repeat my argument: having a per-device default is equal to having no default. We may as well abandon the idea of talking about defaults in that case. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7357 / Virus Database: 4522/11549 - Release Date: 02/03/16
