Mitch, Ah ... I didn't see this before I responded to Thiago - I think my response complements your comments.
Ravi Subramaniam Principal Engineer Intel - (408) 765-3566 > On Feb 4, 2016, at 1:50 PM, Mitch Kettrick <cpm at openinterconnect.org> > wrote: > > 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:thiago.macieira at intel.com] > 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 >
