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.
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.
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?
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..
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:[email protected]] 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
