Hi Wouter, On Thu, Dec 10, 2015 at 1:57 PM, Wouter van der Beek (wovander) <wovander at cisco.com> wrote: > Hi Zoltan, > > The server has to indicate which parameters and ranges can be used by the > client. > (which is just the one liner in the email below...) > That is the negotiation protocol that Ravi indicates below.
In the case of a server resource, Ravi mentioned the bounds to the sampling&update rate could be part of the resource data model (representation). Since observe is just a flag on retrieve request, it would be logical to keep it part of the resource data model. However, if we make an observe protocol, we can explicitly map these parameters to a negotiation mechanism. My impression is we don't necessarily need to do it in an explicit way. > > Hence to get an full-fledged solution parameters like (just thinking out > loud): > - minimal/maximal requested moderation time > - start time? > - which value to send: avg/max/min of moderated time, current value (if > changed). > - value step change > e.g. if this step change has occurred within the requested moderation > time , send something anyway.. > needs to be indicated on the server as possible input parameters that an > client can use. You are right, one more parameter would be the filter (avg/peak/min/etc) to be applied to the samples sent. This is important with certain types of sensors, and can optimize traffic quite heavily. Filters are application dependent and I'd say they belong to the resource model as well. Basically they would be an opaque string to the protocol. > Note that these parameters has to be stored per request, hence additional > requirements needs to be taken care off: > - indication that this mechanism is available > - indicate amount of slots to store this data > - what happens if all slots are full? Applications may be very different with regards to what requirements they have to data latency and fulfilled rates. I'd say the server should send what is possible, together with the fulfilled values of the parameters. Most of the time that will be good enough. The client can decide whether to use them and whether to continue observing, or choose another resource. > Maybe an broker on the network could do this on behalf of the clients. So > that not all devices have to implement this additional scheme.. Yes, servers need to support it anyway. For clients... I think if the broker is local to the client then it could be regarded as an implementation detail / local optimization, and that doesn't change the protocol. If it's in the network, then I surmise it doesn't really help because we will have the same issues between the broker and the client. Besides, it may introduce a state in the network, if we think about the same thing. The primary use case is still that clients could specify a smaller data flow than what the server would be theoretically capable of. Therefore, I'd keep the solution the simplest possible which solves this particular use case. It would be still much better than the current lack of support :). In general, that would mean the possibility for parameters with the observe indication, and support with fulfilled values of parameters for the response. In most cases the fulfilled values would be the same as the requested ones, i.e. the server would satisfy the request. The application (server/client) model defines the ranges - and developers will know the semantics of the data, therefore the applicable rates, before they write code for the request. They will also know if the fulfilled parameters are good enough. At least that is the case with the applications I have in mind. Anyway I let you think about these - just wanted to ask if this was or could be supported later. Best regards, Zoltan > > I think this is an good idea.. but we need to think about it (as Ravi > indicated) and come up with an proper design.. > > Kind Regards, > Wouter > > -----Original Message----- > From: cftg at openinterconnect.org [mailto:cftg at openinterconnect.org] On > Behalf Of Kis, Zoltan > Sent: 10 December 2015 11:36 > To: Subramaniam, Ravi <ravi.subramaniam at intel.com> > Cc: cftg at openinterconnect.org; iotivity-dev at lists.iotivity.org > Subject: Re: [cftg] Observe indication with parameters > > Hi Ravi, > > Thank you for the clarifying comments. So it's work in progress, good :). > Indeed it's reminiscent to SDP. Re-negotiations should also be possible. Once > we go there, it is a challenge to keep it simple without over-engineering. > > In this particular case of flow control related negotiation the sample rate > and message rate seem to be enough for describing the upper bounds the server > can handle, but when a new request comes in, that bound may change, and then > the client needs an update, which will complicate the protocol too much. > > But this seems to be a corner case. I expect the typical scenario would be > that the client wants more sparse data than what the server could > theoretically send. > > In order to keep things simpler, I suggest the following observation protocol: > > - The client makes the request with given parameters. > - The server starts sending data with its best effort to meet the request > parameters, together with the actually accomplished values of the parameters. > - If the client is not happy with that, could stop observing. > > I think this would be simpler and would work well also with the corner cases. > It would also cover QoS, because if the required QoS cannot be met, the > client will get notified, and can decide to cancel the observation. > > Best regards, > Zoltan > > > On Thu, Dec 10, 2015 at 3:44 AM, Subramaniam, Ravi <ravi.subramaniam at > intel.com> wrote: >> Hi Zoltan, >> >> You are right in your general observation >> >> For #2 - (based on current spec) it would have to be based on what >> properties that the resource exposes - if the resource exposes a >> couple of additional properties like "data sample size" and "message >> rate" then the query part of the request can be used to specify the >> bounds on these properties. the reason that "Observe" is defined a >> "request that is cached against the resource and then *evaluated* >> against that resource whenever the state of that resource changes" is >> to allow for the request to be evaluated and only if the query >> parameters evaluations are met in such a way that a response is sent - >> no response is sent if the evaluation fails. NOTE: this OIC statement >> on Observe is different from CoAP which has no evaluation requirement >> (going from memory based on my last reading of CoAP Observe. (So #1 >> below is the mode of operation only if the query part of the request >> only has the observe flag) >> >> For #3 - this would require a "negotiation" process (which is a work item >> that I am working on). The reason is that there is an "offer" with the >> required QoS (i.e. 1KHz sampling with 1 message per second rate) and there >> is a "counter offer" from the server indicating what it can provide this >> client (i.e. 500 sampling rate with 1msg/sec); note this does not have to be >> fixed but could depend on the processing and resource load of the server at >> the time the observe request is made). The client then has to accept or >> reject that counter offer and then the two parties should agree on the final >> values (which *may* take a few more rounds). (This general negotiation flow >> is for many other items and has more considerations than the simple outline >> here but is to address situations like in the observe case #3). >> >> We also have to clearly define QoS - so there is more work to be done here. >> >> Thanks for raising these cases ... >> >> Ravi >> >> -----Original Message----- >> From: cftg at openinterconnect.org [mailto:cftg at openinterconnect.org] On >> Behalf Of Kis, Zoltan >> Sent: Wednesday, December 9, 2015 7:03 AM >> To: cftg at openinterconnect.org >> Cc: iotivity-dev at lists.iotivity.org >> Subject: [cftg] Observe indication with parameters >> >> Hello, >> >> I would like to ask if OIC has a solution for the following flow control >> related use cases: >> >> 1. client1 wants to observe sensor1, and wants 1 update message sent per >> second with 1 reading sample. >> >> 2. client2 wants to observe sensor1, and wants the data sampled with >> 100 Hz, but max 1 message per 10 seconds (each update containing >> 100*10 samples). >> >> 3. client3 wants to observe sensor1, and wants data sampled with 1 KHz, with >> 1 message per second. The server1 response is an error telling "I cannot >> handle that, but I could handle max 500 Hz sampling rate with 1 message per >> second", or "I could handle max 1000 Hz sampling rate with 1 message in 2 >> seconds". Then client3 can decide if it wants to observe still, and modify >> the observe parameters. >> >> So far OIC seems to support for the first use case, but not 2 and 3. >> >> My reasoning: in the client I want to avoid a flood of unneeded updates, and >> in the sensor implementation I want to use the observe parameters to >> optimize power, networking etc resources. >> >> It would be nice to have an optional parameter to observe indication, >> telling a desired sampling rate, and a desired update rate (or the number of >> samples per update message). >> The default value for these could be 1 sample for each update, with the >> update message sent at the server discretion (whenever the value changes, or >> as frequently the server can send it). >> >> Best regards, >> Zoltan
