Opened 9 years ago

Closed 9 years ago

#341 closed other technical (fixed)

Observe sequence number specification not robust against imprecise clocks

Reported by: cabo@… Owned by: draft-ietf-core-observe@…
Priority: major Milestone: post-WGLC-1
Component: observe Version: observe-10
Severity: Active WG Document Keywords:


The specification of sequence number arithmetic in observe-10 appears
to assume that the clocks of clients and servers are perfectly in sync.
However, constrained nodes often have rather imprecise clocks.
(In particular, they may want to fall back to RC clocks during
low-power idle times. These are often accurate only to ± 5 %, if
Inaccuracies of the client and server side may cancel out or add in

It is not hard to add robustness to the existing scheme, by reducing
the maximum notification rate.
Section 4.4 notes that the current scheme can support a notification
rate of up to 64 KiHz?.
Reducing this to 32 KiHz? is still well beyond the highest known design
objective of around 1 kHz (most CoAP applications will be several
orders of magnitude below that), but allows total clock inaccuracies
of up to -50/+100 %.

New language should point out that client and server clocks may differ
in their realization of the SI second, and that staying at a sequence
number increase rate of less than 32 KiHz? (enabling the same
notification rate if there is a strict relationship between sequence
number increases and notificatione) should still be safe in most
real-world cases.

Change History (1)

comment:1 Changed 9 years ago by hartke@…

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

Fixed in [1503]:

Close #341

Note: See TracTickets for help on using tickets.