Subject: [core] Delivery order of notifications in draft-ietf-core-observe-06

From: Alessandro Ludovici <[email-masked]>
Date: Thu, 13 Sep 2012 15:56:20 +0200

Dear List, 

The current definition of the observe draft does not
specify any mechanism for deciding in which order the server should send
the notifications. According to section 4.2: 

"If there are multiple
clients on the list of observers, the order in which they are notified
is not defined; the server is free to use any method to determine the
order". 

My suggestion is that the draft should clearly define the
delivery order of the notifications.  

For instance, in e-emergency
applications the notification of a critical event must be prioritized to
those observers in charge of reacting to it. These nodes could also be
interested only in being notified in a case a critical event occurs.
Furthermore, an alarm could be interested in being notified only when a
critical event occurs and when it ends. Instead, observers that are used
for monitoring purpose could be interested in receiving all the
notifications. 

 Reasons: 

- Observers could have different delay
requirements. 

- The delay of a notification is strongly affected by
the delivery order. 

- Observers could be interested in receiving only
some particular notifications. 

- The observe draft would add QoS
support for timeliness and guarantee on-time delivery to clients
interested in it. 

Requirements: 

- The server should be able to
prioritize the delivery of notifications to observers requiring it. 

-
The server should be able to distinguish which notifications send to a
particular observer. 

Commonly, the server has not information about
the clients. The server only has information about the resource that is
exposing. Therefore, the clients should be able to require a priority
level and to indicate which kind of notifications they wish to receive.

 Proposal: 

A notification should be classified as critical or
non-critical. The server must be the only component that has the
authority to make this decision. 

Four levels of QoS are proposed. The
value of each level is specified using the two most significant bits of
the observe option value (QoS field). This modification affects only the
requests sent by observers for registering and the consequent response
of the subject. The definition of the four QoS level and the relative
QoS field values is the following: 

- Level 1: The subject sends
non-critical and critical notifications with low priority. The value of
the QoS field is 00. 

- Level 2: Both non-critical and critical
notifications are sent with medium priority. The value of the QoS field
is 01. 

- Level 3: The subject sends only critical notification with
high priority. The value of the QoS field is 10. 

- Level 4: The
subject notifies with the highest priority only the start and the end of
a critical state. The value of the QoS field is 11. 

Should more than
one observer require the same level, the subject should order them
following the order at which their requests arrived. 

The client and
the server must be able to negotiate the QoS level. A server, in fact,
should have the faculty to reject or negotiate the demanded QoS. Should
the server accepts the request, it replies with the observe option
containing the QoS value requested. The server expresses its willingness
to negotiate the QoS by replying with the offered QoS. Should the
clients accepts, it would send a response containing the offered QoS.
The server can reject the offer by ignoring it. 

Benefits: 

We run
tests focused on evaluating the effects that this proposal has on a WSN
adopting the observe extension. The tests are done in a real WSN using
TelosB motes. The requirements of the observe extension application are
those of an e-health network used for monitoring the cardiac rate of a
patient. The performance evaluation has been done in terms of delay,
delivery ratio and energy consumption. 

- The results confirm that the
delivery order of a notification influence both the delay and delivery
ratio. 

- The first notifications sent by a subject experience less
delay and have a high delivery ratio. 

- The energy consumption of the
subject is considerably reduced if observers are able to express the
notification class of interest. 

 This proposal and the experimental
results are contained in a forthcoming paper to be presented at the IEEE
WiMOB conference (8-10 October 2012). The tile of the paper is "Adding
QoS Support For Timeliness To The Observe Extension Of CoAP". It is not
yet available in the IEEExplorer. However, I can send it to those
interested. 

 Regards, 

Alessandro Ludovici 

-- 
Wireless Network
Group(WNG), 
Department of Telematic Engineering, 
Universitat
Politècnica de Catalunya, 
C/Jordi Girona 1-3, Mòdul C3, 08034
Barcelona, Spain; 
E-Mail: [email-masked] 
Tel.:
+34-93-401-70-41; Fax: +34-93-401-10-58

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 13 Sep 2012 19:58:16 +0300

Hi Alessandro,

I've read your paper and find it quite interesting. However, it builds
on a wrong premise.

CoAP-observe does not deliver events.

Its emphasis is on the state of a resource at some server and the copy
of the state that a client has, not on the messages that are exchanged
between the two. The goal is to have the copy be as consistent as
possible with the original. This means that the copy should be updated
as soon as possible when the resource state changes. While it's not a
goal to guarantee that this update happens within a particular time
span (quite the opposite is the case), it is a goal that this time
span is kept as short as possible. One means to achieve this is not to
try to get every resource state to the client, but just the latest.

If prioritization of clients helps with this in some application
scenarios, I think it would be worthwhile to consider. I'd be
interested to see the evaluation of the presented example after
updating it to the right model.

Klaus

On 13 September 2012 16:56, Alessandro Ludovici
<[email-masked]> wrote:
> Dear List,
>
> The current definition of the observe draft does not specify any mechanism
> for deciding in which order the server should send the notifications.
> According to section 4.2:
>
> “If there are multiple clients on the list of observers, the order in which
> they are notified is not defined; the server is free to use any method to
> determine the order”.
>
> My suggestion is that the draft should clearly define the delivery order of
> the notifications.
>
> For instance, in e-emergency applications the notification of a critical
> event must be prioritized to those observers in charge of reacting to it.
> These nodes could also be interested only in being notified in a case a
> critical event occurs. Furthermore, an alarm could be interested in being
> notified only when a critical event occurs and when it ends. Instead,
> observers that are used for monitoring purpose could be interested in
> receiving all the notifications.
>
>  Reasons:
>
> -          Observers could have different delay requirements.
>
> -          The delay of a notification is strongly affected by the delivery
> order.
>
> -          Observers could be interested in receiving only some particular
> notifications.
>
> -          The observe draft would add QoS support for timeliness and
> guarantee on-time delivery to clients interested in it.
>
> Requirements:
>
> -          The server should be able to prioritize the delivery of
> notifications to observers requiring it.
>
> -          The server should be able to distinguish which notifications send
> to a particular observer.
>
> Commonly, the server has not information about the clients. The server only
> has information about the resource that is exposing. Therefore, the clients
> should be able to require a priority level and to indicate which kind of
> notifications they wish to receive.
>
>  Proposal:
>
> A notification should be classified as critical or non-critical. The server
> must be the only component that has the authority to make this decision.
>
> Four levels of QoS are proposed. The value of each level is specified using
> the two most significant bits of the observe option value (QoS field). This
> modification affects only the requests sent by observers for registering and
> the consequent response of the subject. The definition of the four QoS level
> and the relative QoS field values is the following:
>
> -          Level 1: The subject sends non-critical and critical
> notifications with low priority. The value of the QoS field is 00.
>
> -          Level 2: Both non-critical and critical notifications are sent
> with medium priority. The value of the QoS field is 01.
>
> -          Level 3: The subject sends only critical notification with high
> priority. The value of the QoS field is 10.
>
> -          Level 4: The subject notifies with the highest priority only the
> start and the end of a critical state. The value of the QoS field is 11.
>
> Should more than one observer require the same level, the subject should
> order them following the order at which their requests arrived.
>
> The client and the server must be able to negotiate the QoS level. A server,
> in fact, should have the faculty to reject or negotiate the demanded QoS.
> Should the server accepts the request, it replies with the observe option
> containing the QoS value requested. The server expresses its willingness to
> negotiate the QoS by replying with the offered QoS. Should the clients
> accepts, it would send a response containing the offered QoS. The server can
> reject the offer by ignoring it.
>
> Benefits:
>
> We run tests focused on evaluating the effects that this proposal has on a
> WSN adopting the observe extension. The tests are done in a real WSN using
> -          The results confirm that the delivery order of a notification
> influence both the delay and delivery ratio.
>
> -          The first notifications sent by a subject experience less delay
> and have a high delivery ratio.
>
> -          The energy consumption of the subject is considerably reduced if
> observers are able to express the notification class of interest.
>
>  This proposal and the experimental results are contained in a forthcoming
> paper to be presented at the IEEE WiMOB conference (8-10 October 2012). The
> tile of the paper is “Adding QoS Support For Timeliness To The Observe
> Extension Of CoAP”. It is not yet available in the IEEExplorer. However, I
> can send it to those interested.
>
>  Regards,
>
> Alessandro Ludovici

---

From: Lishitao <[email-masked]>
Date: Fri, 14 Sep 2012 01:49:42 +0000

Hi

I think the QoS requirements for observe make any sense. It is similar with our conditional observe idea, which can be found at http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/.
But instead of providing the QoS level into the request, put the client requirements is more appropriate. Because, the QoS information send from the client, may not be trusted by the server. I guess every client hope to be served with the highest priority. But the client can provide its tolerant delay time for response, the serve can decide the order according to this information.

Regards
shitao

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Ludovici
Sent: Thursday, September 13, 2012 9:56 PM
To: [email-masked]
Subject: [core] Delivery order of notifications in draft-ietf-core-observe-06

Dear List,

The current definition of the observe draft does not specify any mechanism for deciding in which order the server should send the notifications. According to section 4.2:

“If there are multiple clients on the list of observers, the order in which they are notified is not defined; the server is free to use any method to determine the order”.

My suggestion is that the draft should clearly define the delivery order of the notifications.

For instance, in e-emergency applications the notification of a critical event must be prioritized to those observers in charge of reacting to it. These nodes could also be interested only in being notified in a case a critical event occurs. Furthermore, an alarm could be interested in being notified only when a critical event occurs and when it ends. Instead, observers that are used for monitoring purpose could be interested in receiving all the notifications.

 Reasons:

-          The delay of a notification is strongly affected by the delivery order.

-          Observers could be interested in receiving only some particular notifications.

-          The observe draft would add QoS support for timeliness and guarantee on-time delivery to clients interested in it.

Requirements:

-          The server should be able to prioritize the delivery of notifications to observers requiring it.

-          The server should be able to distinguish which notifications send to a particular observer.

Commonly, the server has not information about the clients. The server only has information about the resource that is exposing. Therefore, the clients should be able to require a priority level and to indicate which kind of notifications they wish to receive.

 Proposal:

A notification should be classified as critical or non-critical. The server must be the only component that has the authority to make this decision.

Four levels of QoS are proposed. The value of each level is specified using the two most significant bits of the observe option value (QoS field). This modification affects only the requests sent by observers for registering and the consequent response of the subject. The definition of the four QoS level and the relative QoS field values is the following:

-          Level 1: The subject sends non-critical and critical notifications with low priority. The value of the QoS field is 00.

-          Level 2: Both non-critical and critical notifications are sent with medium priority. The value of the QoS field is 01.

-          Level 3: The subject sends only critical notification with high priority. The value of the QoS field is 10.

-          Level 4: The subject notifies with the highest priority only the start and the end of a critical state. The value of the QoS field is 11.

Should more than one observer require the same level, the subject should order them following the order at which their requests arrived.

The client and the server must be able to negotiate the QoS level. A server, in fact, should have the faculty to reject or negotiate the demanded QoS. Should the server accepts the request, it replies with the observe option containing the QoS value requested. The server expresses its willingness to negotiate the QoS by replying with the offered QoS. Should the clients accepts, it would send a response containing the offered QoS. The server can reject the offer by ignoring it.

Benefits:

We run tests focused on evaluating the effects that this proposal has on a WSN adopting the observe extension. The tests are done in a real WSN using TelosB motes. The requirements of the observe extension application are those of an e-health network used for monitoring the cardiac rate of a patient. The performance evaluation has been done in terms of delay, delivery ratio and energy consumption.

-          The results confirm that the delivery order of a notification influence both the delay and delivery ratio.

-          The first notifications sent by a subject experience less delay and have a high delivery ratio.

-          The energy consumption of the subject is considerably reduced if observers are able to express the notification class of interest.

 This proposal and the experimental results are contained in a forthcoming paper to be presented at the IEEE WiMOB conference (8-10 October 2012). The tile of the paper is “Adding QoS Support For Timeliness To The Observe Extension Of CoAP”. It is not yet available in the IEEExplorer. However, I can send it to those interested.

 Regards,

Alessandro Ludovici

--

Wireless Network Group(WNG),

Universitat Politècnica de Catalunya,

C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain;

Tel.: +34-93-401-70-41; Fax: +34-93-401-10-58

---

From: Alessandro Ludovici <[email-masked]>
Date: Fri, 14 Sep 2012 14:50:09 +0200

Hi, 

Klaus: 

I would provide new results as soon as I update the
model and re-run the experiments. I have to figure out how the observe
premises could affect the model. Any comments or suggestions are very
welcome. 

Shitao: 

Although my proposal and conditional observe are
similar they have different premises and implications. Conditional
observe adds more complexity at server side. Considering the processing
and memory limitations of a typical constrained server, multiple
conditional requests could cause a very high workload when the server
has to send notifications. My proposal tries to be as simple as possible
in order to reduce the implementation complexity and resource
consumption. However, the goal is the same. Reduce the network traffic
by avoiding sending messages that the clients do not need is of
paramount importance. 

Regarding the priority delivery my opinion is
that not any client needs to be served with highest priority. Each
client has different role and different requirements. As an example, an
alarm must receive the information before than a client used to monitor
the resource and store its state in some database. Depending on how many
observers have to be served, the delay between the firsts to be served
and the last could be very large. 

The problem that a server may not
trust a client is a much more general problem that does not affect only
the delivery order. Multiple untrusted/malicious clients could send
observe or conditional observe requests to a server and fulfill quickly
its buffer and cause a denial of service. 

On Fri, 14 Sep 2012 01:49:42
+0000, Lishitao wrote: 

> Hi 
> 
> I think the QoS requirements for
observe make any sense. It is similar with our conditional observe idea,
which can be found at
http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/ [1].

> 
> But instead of providing the QoS level into the request, put the
client requirements is more appropriate. Because, the QoS information
send from the client, may not be trusted by the server. I guess every
client hope to be served with the highest priority. But the client can
provide its tolerant delay time for response, the serve can decide the
order according to this information. 
> shitao 
FROM: [email-masked] [mailto:[email-masked]] ON BEHALF OF
Alessandro Ludovici
> SENT: Thursday, September 13, 2012 9:56 PM
> TO:
[email-masked]
> SUBJECT: [core] Delivery order of notifications in
draft-ietf-core-observe-06 
> The current definition
of the observe draft does not specify any mechanism for deciding in
which order the server should send the notifications. According to
section 4.2: 
> 
> "If there are multiple clients on the list of
observers, the order in which they are notified is not defined; the
server is free to use any method to determine the order". 
> My
suggestion is that the draft should clearly define the delivery order of
the notifications. 
> 
> For instance, in e-emergency applications the
notification of a critical event must be prioritized to those observers
in charge of reacting to it. These nodes could also be interested only
in being notified in a case a critical event occurs. Furthermore, an
alarm could be interested in being notified only when a critical event
occurs and when it ends. Instead, observers that are used for monitoring
purpose could be interested in receiving all the notifications. 

order. 
> 
> Requirements: 
> 
> - The server should be able
to prioritize the delivery of notifications to observers requiring it.

> Commonly, the server has not
information about the clients. The server only has information about the
resource that is exposing. Therefore, the clients should be able to
require a priority level and to indicate which kind of notifications
they wish to receive. 
> A notification should be
classified as critical or non-critical. The server must be the only
component that has the authority to make this decision. 
> Four
levels of QoS are proposed. The value of each level is specified using
the two most significant bits of the observe option value (QoS field).
This modification affects only the requests sent by observers for
registering and the consequent response of the subject. The definition
of the four QoS level and the relative QoS field values is the
- Level 2: Both non-critical and critical notifications are sent with
medium priority. The value of the QoS field is 01. 
> - Level 3: The
subject sends only critical notification with high priority. The value
of the QoS field is 10. 
> 
> - Level 4: The subject notifies with the
highest priority only the start and the end of a critical state. The
value of the QoS field is 11. 
> 
> Should more than one observer
require the same level, the subject should order them following the
order at which their requests arrived. 
> 
> The client and the server
must be able to negotiate the QoS level. A server, in fact, should have
the faculty to reject or negotiate the demanded QoS. Should the server
accepts the request, it replies with the observe option containing the
QoS value requested. The server expresses its willingness to negotiate
the QoS by replying with the offered QoS. Should the clients accepts, it
would send a response containing the offered QoS. The server can reject
the offer by ignoring it. 
> We run tests focused on
evaluating the effects that this proposal has on a WSN adopting the
observe extension. The tests are done in a real WSN using TelosB motes.
The requirements of the observe extension application are those of an
e-health network used for monitoring the cardiac rate of a patient. The
performance evaluation has been done in terms of delay, delivery ratio
and energy consumption. 
> 
> - The results confirm that the delivery
order of a notification influence both the delay and delivery ratio. 

Department of Telematic Engineering, 
Universitat Politècnica de
Catalunya, 
C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain;

E-Mail: [email-masked] 
Tel.: +34-93-401-70-41; Fax:
+34-93-401-10-58

Links:
------
[1]
http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 16 Sep 2012 23:02:10 +0300

Alessandro Ludovici wrote:
> I would provide new results as soon as I update the model and re-run the
> experiments. I have to figure out how the observe premises could affect the
> model. Any comments or suggestions are very welcome.

I've taken the opportunity to create a short, illustrated guide to
observing resources:

   http://svn.tools.ietf.org/svn/wg/core/observe/page1.html
   (requires a modern web browser)

I hope this helps to clarify some aspects of -observe. Feedback is welcome.

Klaus

---

From: Jeroen Hoebeke <[email-masked]>
Date: Tue, 18 Sep 2012 09:38:08 +0200

Hi Alessandro,

> Shitao:
> 
> Although my proposal and conditional observe are similar they have different premises and implications. Conditional observe adds more complexity at server side. Considering the processing and memory limitations of a typical constrained server, multiple conditional requests could cause a very high workload when the server has to send notifications.
> My proposal tries to be as simple as possible in order to reduce the implementation complexity and resource consumption. However, the goal is the same. Reduce the network traffic by avoiding sending messages that the clients do not need is of paramount importance.

Introducing additional processing at the server side always adds more complexity (more state info, more processing). For conditional observe this includes storage of some additional state information (the condition and value) and condition checking. Conditional observe aims to reduce the number of times you transfer the state of the resource. We implemented and evaluated this concept on Sky nodes having 48kB ROM. The advantage of being able to reduce the number of transmissions outweighs the slightly increased complexity. 

For your priority delivery, you will also have some additional overhead at the server side (you could even implement it as a condition indicating the priority level). It could be an extension to observe.

Another question about the prioritisation: how can you guarantee this delivery order in larger networks? In larger networks, it would better to let an intermediary establish a single observation relationship to the constrained device on behalf of all interested observers and apply the prioritisation at the intermediary. Then all observers can benefit.

Kind regards,
Jeroen

---

From: Alessandro Ludovici <[email-masked]>
Date: Tue, 18 Sep 2012 10:43:48 +0200

Hi Jeroen, 

> Introducing additional processing at the server side
always adds more complexity (more state info, more processing). For
conditional observe this includes storage of some additional state
information (the condition and value) and condition checking.
Conditional observe aims to reduce the number of times you transfer the
state of the resource. We implemented and evaluated this concept on Sky
nodes having 48kB ROM. The advantage of being able to reduce the number
of transmissions outweighs the slightly increased complexity. 
> For
your priority delivery, you will also have some additional overhead at
the server side (you could even implement it as a condition indicating
the priority level). It could be an extension to observe.

Priority
delivery does not need to store state info at server-side. The list of
observers can be organized following the priority delivery order. On the
top of this list there would be the observers that the server have to
notify with the highest priority and so on. The only (small)
extra-processing required is in the organization of the list.
Furthermore, the client expresses the desired priority level using the
two most significant bytes the observe option value. The advantage of
this is that we do not add overhead.

As Klaus suggested in its guide to
observing resources
(http://svn.tools.ietf.org/svn/wg/core/observe/page1.html [1]), a server
could expose more that on resource for storing the same state
information. In a hearth rate monitoring application, a resource could
expose only critical state of the rate while another would transfer the
state in any condition. I think this could be a good suggestion for
reducing the number of transmissions. I will test it in my priority
delivery model. However, there could be situation where creating many
resources could be wasteful and the use of conditional observer would
work better. 

> Another question about the prioritisation: how can you
guarantee this delivery order in larger networks? In larger networks, it
would better to let an intermediary establish a single observation
relationship to the constrained device on behalf of all interested
observers and apply the prioritisation at the intermediary. Then all
observers can benefit.

In this case, the intermediary would be in
charge of the priority delivery. Clients will only establish the
observation with the intermediary. 

Regards, 

Alessandro Ludovici

Links:
------
[1]

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 19 Sep 2012 13:40:24 +0300

Alessandro Ludovici wrote:
> However, there could be situation where creating many resources
> could be wasteful and the use of conditional observer would work better.

Using multiple resources is not more wasteful than what you have
described; the overhead is exactly the same. You just put your two
bits in the request URI rather than the Observe Option. The same
applies to -conditional-observe.

Klaus

---

From: Alessandro Ludovici <[email-masked]>
Date: Mon, 24 Sep 2012 19:10:24 +0200

Hi, 

After Klaus's suggestions I have updated the priority
delivery model. This version does not define any mechanism to allow
clients to observe only the states they wish to receive. Conditional
observe or the use of parameterized resources could be used instead.

The new model defines three levels of delivery priority. A client uses
the two most significant bits of the observe option value to require the
desidered priority level (Priority field). This is only present in the
requests sent by clients to observe a resource and in the consequent
response of the server. The definition of the three levels and the
relative Priority field values is the following: 

- High: the value of
the Priority field is 10. 

- Medium: the value of the Priority field is
01. 

- Low: the value of the Priority field is 00. 

Should a server
receives multiples request for the same level of priority, it orders
them following the arrival order. 

I've done the delay tests all over
again. The delay has been calculated as the time elapsed from the moment
the server sends the first update on the resource's state until a client
receives it. The update have been sent using NON messages. Energy
consumption and delivery ratio have not being evaluated since they are
metrics that are not influenced by priority delivery. 

The tests are
done in a star-topology WSN using TelosB motes. I considered six
different situations where each of them has a different number of
clients observing the same resource (from two to six). The application
requirements are those of an e-health network used for monitoring the
cardiac rate of a patient. The server sends updates each 200 ms when the
patient is in a critical state. The payload has a length of 2 bytes and
contains the hearth rate obtained averaging the two last measures. 

Results are reported in the file attached to this e-mail. 

 Alessandro