Opened 11 years ago

Closed 11 years ago

#174 closed protocol defect (fixed)

Robust observation relationships

Reported by: hartke@… Owned by: hartke@…
Priority: major Milestone:
Component: observe Version:
Severity: Submitted WG Document Keywords:
Cc:

Description

Observe is a little bit too happy to drop an observation relationship at the slightest sign of trouble.

There must be some way for a server to decide if the client is still there, and a way for a client to decide if the server is still sending notifications, without sending a ping every second.

Solution: Some agreement on how long after the latest notification the client can be safely assume that the server will continue to send notifications, and the server can safely assume that the client is still interested.

Change History (6)

comment:1 Changed 11 years ago by hartke@…

  • Resolution set to fixed
  • Status changed from new to closed

Clear rules for what to do when a client does not receive a notification for some time, or a server does not receive an acknowledgement, have been added in observe-03. The time to wait is determined by Max-Age and a new option called Max-OFE ("optimistic freshness extension").

comment:2 Changed 11 years ago by cabo@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

In Taipei, we had a discussion about the complexity caused by Max-OFE. Instead of coupling the hold-off for re-establishing observation relationships to freshness, we should keep the two concepts separate. An option sent by the server to the client could indicate the amount of time the server promises not to give up the observation relationship. Making this time relative to the point in time when freshness runs out allows a convenient default of 0.

comment:3 Changed 11 years ago by cabo@…

A proposal for a solution is in coap-misc-12 ("Pledge"). There may be no need to put this in the base -observe spec.
Do we need to keep this ticket open (i.e., to indeed make the addition in the base -observe?)

comment:4 Changed 11 years ago by cabo@…

If Pledge or something similar is the medium-term solution, maybe there is one last thing that could be added to base -observe now:
An implementation note with a short discussion of the inaccuracy of clocks and the influence of propagation delays — a naive implementation might have the re-subscribe of the client and new notification after max-age cross over each other.

comment:5 Changed 11 years ago by hartke@…

Replace the penultimate paragraph of section 3.4 with the following two paragraphs:

To make sure it has a fresh representation and/or to re-register its interest, a client MAY issue a new GET request with an Observe Option at any time. The GET request SHOULD specify a new token to avoid ambiguity, because the token serves as epoch identifier for the sequence numbers in the Observe Option (see Section 3.4).

It is RECOMMENDED that the client does not issue the request while it still has a fresh notification and, beyond that, while a new notification from the server is still likely to arrive. I.e. the client should wait until the age of the last notification becomes greater than its Max-Age plus the potential retransmission window (see Section 4.1 of [I-D.ietf-core-coap]) plus the expected maximum round trip time.

comment:6 Changed 11 years ago by hartke@…

  • Resolution set to fixed
  • Status changed from reopened to closed

Done.

Note: See TracTickets for help on using tickets.