Re: [core] #217: how fast must the observe clock be able to go?

Dear list

Here an alternative for the observe clock as sketched during the interim:

To fix the problem with resources that can change with a very high frequency (1kHz was mentioned...), we could make the Observe option larger than 16 bits and really treat it as an variable length integer instead of a fixed counter (i.e., we could use up to 4 bytes and do not have to count up to 2**32-1).

The ticks per second are then chosen to match the "change frequency" of the resource, so that the current check of the expired time between two messages still holds: no wrap around for T2 < (T1 + expiry) (see Observe-05, 3.4.). As the server takes care of resetting the Observe clock, the client does not need to care about the actual ticks per second.
Instead of expiry=2**14, we now have to define an upper bound for the time messages can remain in the network and use a value given in seconds.
Maybe we can derive that time from the congestion control issue...

I hope this what you expected, Carsten. Otherwise, I am happy to hear you interpretation of what I said during the interim :)

This of course is in favor of a per-resource clock to keep the Observe option small for slowly changing resources.
I also like the idea of having a continuous clock (apart from the recognizable resets), so clients can identify missing notifications.

Ciao
Matthias

> We could go to a larger sequence number (e.g., 3 bytes, typically implemented
> as mibiseconds, leading to a window of 4096 seconds and a wrap-around at
> 16384 seconds), but this would burden all implementations with these 3-byte
> sequence numbers and still have an arbitrary limitation.
> 
> The best "scalable" version of this we came up with so far is:
> Make "Observe" repeatable.  A second instance of the option provides a
> "fractional part" of the number -- not really fractional, but disambiguating
> multiple instances that have the same 16-bit sequence number.
> 
> So, if 1, 2, 3 is too slow for you, use
> 1/0, 1/1, 1/2, 2/0, 2/1, 2/2, 2/3, 3/0, 3/1 etc.
> 
> Hmm.
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core