Subject: [core] Notifying unresponsive clients (was Re: Comments on draft-ietf-core-coap-03)

From: Klaus Hartke <[email-masked]>
Date: Tue, 2 Nov 2010 18:25:27 +0100

Peter Bigot wrote:
> There must be some limit: constrainedness should not excuse clearly
> undesirable behavior.

In the context of CoAP-observe, it is undesirable to transmit the
representation of a resource state that has already changed long ago.

So what we need is some strategy that deals with the case when a
resource state changes and the observer hasn't acknowledged the last
confirmable notification.

There are many reasons why an observer might not have acknowledged the
last confirmable notification:

- there's a short interruption in message delivery,
- the client's battery has run out of charge,
- the client can't keep up with processing the notifications,
- the network is congested,
- etc.

We want a server to end a subscription when the client is gone, but we
don't want to end a subscription just because there's a short hiccup
in the network.

I came up with the following possible solutions:

(a) Set MAX_RETRANSMIT for confirmable notifications to 1.

(b) Do not allow confirmable notifications while a confirmable
notification is pending.

(c) Cancel pending confirmable notifications when the next confirmable
notification is to be sent.

(d) Do not transmit a snapshot, but a representation of the state that
is current at the instant of the retransmission.

Solution (a) ends a subscription prematurely when a single message
goes missing. (b) is undesirable, because it makes not a lot of sense
to insist on transmitting a state that has already changed. (c)
doesn't end the subscription when the client is gone but the state
constantly changes before the end of the retransmission window. So (d)
looked like a good choice when I added the recommendation to
CoAP-observe. This doesn't mean this cannot be further improved.

Thinking about it, there is another solution that I haven't thought of yet:

(e) Cancel the pending confirmable notification and send the new
confirmable notification with MAX_RETRANSMIT set to the number of
attempts remaining from the canceled notification.

Does that make sense?

Klaus