Subject: [core] #220: Should observer support time series data?

From: "core issue tracker" <[email-masked]>
Date: Fri, 20 Apr 2012 14:56:48 -0000

#220: Should observer support time series data?

 Jeroen Hoebeke notes (msg02900):

 There is a difference between the following:

 1. informing a client about every change of the state of a resource: this
 is what one would expect when just reading the abstract of the draft

 2. delivering a client an always fresh representation of a resource (even
 if the resource did not change): this is what the draft actually
 implements through the max-age option

 Having both makes a lot of sense. Draft observe could fulfill both
 purposes (and would be a good place to do so). If draft observe is only
 about 1) and the abstract clarifies this, an extension to observe
 (introducing pledge) for case 2) seems an obvious step. Personally, I am
 in favor of having this in a single draft.

 ->

 Observe currently is about 2 (eventual consistency).  What kinds of
 mechanisms would we need to add to support time series data as in 1?  Is
 the resulting set of changes a desirable addition?

-- 
----------------------------------+---------------------------------------
 Reporter:  cabo@…                |      Owner:  draft-ietf-core-observe@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  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/220>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Fri, 20 Apr 2012 14:58:04 -0000

#220: Should observe support time series data?

Description changed by cabo@…:

> the resulting set of changes a desirable addition?

New description:

 ->

 (see also #219)

--

-- 
----------------------------------+----------------------------------------
 Reporter:  cabo@…                |       Owner:  draft-ietf-core-observe@…
     Type:  protocol enhancement  |      Status:  new
 Priority:  minor                 |   Milestone:  post-WGLC-1
Component:  observe               |     Version:  observe-05
 Severity:  In WG Last Call       |  Resolution:
 Keywords:                        |
----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/220#comment:1>
core <http://tools.ietf.org/core/>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 20 Apr 2012 17:16:56 +0200

>  the resulting set of changes a desirable addition?

With (1) a rapidly changing resource will quickly fill network
buffers, and lead to congestion collapse... It's not an easy addition
in general.

In my opinion we need some lower bound on the resource update
interval, and some stronger mechanism of congestion control to do
this.

Angelo

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 14:38:24 -0600

I think we want #2 and not #1. If an application wants to arrange it's data so a get returns the buffer of all previous values over a certain horizon, then #2 can be used to implement #1. 

In general,  trying to have guaranteed delivery of anything just does not work out on IP networks. 

On Apr 20, 2012, at 8:56 , core issue tracker wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core