"but smaller packets is always good" I think I get your point, Ravi, but I didn't want to leave this on the table. There are many perspectives from which to judge packet size. From a power point of view, having the packet size match the payload, however long it is, is most power efficient. Recognizing a packet preamble takes time and energy, plus the general packet overhead, plus the application (OIC) overhead, costs considerable energy on a per packet basis, while adding bytes to an existing packet is small marginal cost.
If the designers of BTLE had thought that it would be used for longer packets, as its older brother is, they might have made the default packets longer. As it is, they make the packet size negotiable, recognizing that some uses needed more power-efficient delivery. They saw the uses of BTLE for smaller bits of information, and making the default packets size smaller means most uses are more efficient without requiring extra programming and on-air negotiation, along with other advantages, such as latency for using the channel by other nodes. I'm not disagreeing with any of the arguments expressed on the issue at hand. John Light -----Original Message----- From: oswg at openinterconnect.org [mailto:o...@openinterconnect.org] On Behalf Of Subramaniam, Ravi Sent: Thursday, February 04, 2016 4:50 PM To: Macieira, Thiago Cc: Mitch Kettrick; Maloor, Kishen; oswg at openinterconnect.org; iotivity-dev at lists.iotivity.org Subject: Re: [oswg] Re: [dev] Default interface signaling Thiago, The reason is primarily MTU which given some of the radios we need to target can be pretty small. When considering battery is is not a consideration on a per request or response but when one begins to add extra bytes over time then it does make a difference (remember many IOT devices are expected to last on a battery for months even a year and beyond; some smoke detectors on the market run on a single battery for their entire useful life) - I would agree that fragmentation is a bigger cause of battery life where a device has to keep radio on longer. (We haven't defined all the power considerations in spec but smaller packets is always good) On the second point - I understand your point for simple Resources but when we get to Collections and say the batch Interface using queries is complicated for the client to formulate a request. So giving the client having the option of sending a request without a query portion eases things significantly. When a server indicates the default interface all it is telling the Client - "if you send me a request without a query part then I will interpret that request as if you sent it to the Interface I am telling you is my default" - this makes the semantics of a simple no query request explicit, I don't think the Server is forcing use of the default or selecting an Interface for the Client. Now this default is chosen such that a simple request without query would cover the largest kind of requests expected against the Resource. Given this the Core chose a simple mechanism to communicate the default by using ordering in the discovery response; discovery must be done anyway (whether or not we have default) so that the Client can know which Interfaces it can select from. So there is no extra burden to the Client from designating the default - it just makes it easier for Client to formulate a request in *all* cases i.e. cases with Collections. Now if the Client uses the default semantics fully then we get additional benefits like MTU etc. The use of default is no different from a GUI designer for a mobile app putting the buttons most likely to be used by the user on the home page of the app and burying other options deeper in GUI hierarchy. It is still the user's choice but it does make it easier for the user when the screen is simple and the buttons they are likely to use most often are right there in front. Ravi Subramaniam Principal Engineer Intel - (408) 765-3566 > On Feb 4, 2016, at 1:27 PM, Macieira, Thiago <thiago.macieira at intel.com> > wrote: > >> 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 >
