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

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jun 2012 11:09:31 -0700

After the last call, I'd like to propose one of things we consider is the following:

1) use a 3 byte id value  - the application can set it however it wants subject to the following constrains

2) each value must be larger than previous value modulo 2^24 ( it is allowed to wrap ) 

3) value must not be re-used for at least 256 seconds after first use

Note using a local clock in seconds or mili seconds would be fine. So would an per resources counter. 

First of all, does this sound like it would work? and second, pros / cons vs other approaches?

Cullen

On Apr 19, 2012, at 11:50 , core issue tracker wrote:

> #217: how fast must the observe clock be able to go?
> 
> 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)?
> 
> -- 
> ----------------------------------+---------------------------------------
> Reporter:  cabo@…                |      Owner:  draft-ietf-core-observe@…
>     Type:  protocol enhancement  |     Status:  new
> Priority:  major                 |  Milestone:  post-WGLC-1
> Component:  observe               |    Version:  observe-05
> Severity:  In WG Last Call       |   Keywords:
> ----------------------------------+---------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/217>
> core <http://tools.ietf.org/core/>
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 8 Jun 2012 08:22:31 +0000

This is the direction I was thinking.
The variable length logical clock I had in mind (which would remove the rate limitation) turned out to be very complicated for deciding "larger than," though. So this is where my proposal is currently stuck or got a lot of messy rules.
With a fixed length it is much easier, I must admit. And 65kHz should be enough for resource changes...

Are these 256s a constant of its own or will they be replaced with our MAX_LATENCY (our equivalent to TCP's MSL) or at least derived from that value, like 2*MAX_LATENCY?
Would be nice not to have too many constants of that kind...

Ciao
Matthias

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings
> Sent: Donnerstag, 7. Juni 2012 20:10
> To: core WG
> Cc: [email-masked]
> Subject: Re: [core] #217: how fast must the observe clock be able to go?
> 
> 
> > 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.
> >
> > ->
> >
> > We could come up with alternative, more elaborate server-side
> > requirements that enable faster updates.
> > ----------------------------------+-----------------------------------
> > ----------------------------------+----
> > Reporter:  cabo@...                |      Owner:  draft-ietf-core-observe@...
> > ----------------------------------+-----------------------------------
> > ----------------------------------+----
> >

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 8 Jun 2012 08:29:16 +0000

> Are these 256s a constant of its own or will they be replaced with our
> MAX_LATENCY (our equivalent to TCP's MSL) or at least derived from that
> value, like 2*MAX_LATENCY?

Okay, I got confused with all these MSL-like values. I am talking about this value between 45 and 256 seconds, which is considered a safe time to reuse a sequence number.
We definitely must clean this up!

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 8 Jun 2012 07:46:42 -0400

> We definitely must clean this up!

+1 - yah, I think you are right, it needs to be that number, whatever it is we call it :-)