Opened 10 years ago

Closed 10 years ago

#217 closed protocol enhancement (fixed)

how fast must the observe clock be able to go?

Reported by: cabo@… Owned by: draft-ietf-core-observe@…
Priority: major Milestone: post-WGLC-1
Component: observe Version: observe-05
Severity: In WG Last Call Keywords:


Cullen Jennings notes (msg03073g):

Section 4.4 - I'm confused about the algorithm here. Does this mandate that the resource can ever changes more than once per second ? For many applications I want way faster updates than this. I don't think this works.


The client-side algorithm is specified in 3.4. The current "MUST NOT reuse" in 4.4 is very conservative, reflecting a very simple implementation strategy.
We could come up with alternative, more elaborate server-side requirements that enable faster updates.
How fast is fast enough? How much are we willing to assume about reordering and delivery probabilities (distributions, actually)?

Change History (3)

comment:1 Changed 10 years ago by hartke@…

Current proposal:

  • Option value between 0 and 224-1 (0–3 bytes)
  • Each value must be larger than previous value modulo 224
  • A value must not be re-used for EXCHANGE_LIFETIME

This allows for ~ 216 notifications per second with default parameters

comment:2 Changed 10 years ago by hartke@…

The text needs to put a limit on how much the sequence number may increase per time unit. If the number increases too fast, it may be discarded as too old due to wrap-around.

comment:3 Changed 10 years ago by hartke@…

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

Fixed in [986]:

Closes #217: Done in observe-07

Note: See TracTickets for help on using tickets.