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
