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

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 May 2012 11:08:55 +0200

> 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)?

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

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 16 May 2012 19:41:24 +0000

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.
> 
> 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.
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core