Subject: [core] #129: [Observe] Simplify Reordering

From: "core issue tracker" <[email-masked]>
Date: Fri, 18 Mar 2011 03:31:45 -0000

#129: [Observe] Simplify Reordering

 The paragraph below seems to be complex. Can we simplify this a little
 bit? For example, we can require in the spec like this: if the observe
 value in the response is near or equals to 2^16-1, the observer should
 send a new Get request with the Observe option. Then the server can use
 Observe value starting from 0 to 2^16 again.

    A client MAY discard a notification as outdated (not fresh) under the
 following condition:

       (V1 - V2) % (2^16) < (2^15)    and    T2 < (T1 + (2^14))

    where T1 is a client-local timestamp of the latest valid notification
 received for this resource (in seconds), T2 a client-local timestamp of
 the current notification, V1 the value of the Observe Option of the latest
 valid notification received, and V2 the value of the Observe Option of the
 current notification.  The first condition essentially verifies that V2 >
 V1 holds in 16-bit sequence number arithmetic [RFC1982].  The second
 condition checks that the time expired between the two incoming messages
 is not so large that the sequence number might have wrapped around and the
 first check is therefore invalid (but is not needed any more, because
 reordering is not expected to occur on the order of 2^14 seconds).  Note
 that the constants of 2^14 and 2^15 are non-critical, as is the even speed
 of the clocks involved; e.g., the second check can be implemented by
 marking a response as fresh on reception and downgrading all responses
 periodically every, say, 2^13 seconds; once it has been downgraded twice,
 it no longer participates in freshness checks.

-- 
---------------------------------+------------------------------------------
 Reporter:  likepeng@…           |       Owner:     
     Type:  protocol defect      |      Status:  new
 Priority:  major                |   Milestone:     
Component:  observe              |     Version:     
 Severity:  -                    |    Keywords:     
---------------------------------+------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/129>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Fri, 18 Mar 2011 12:53:23 -0000

Changes (by cabo@…):

  * owner:  => hartke@…
  * priority:  major => minor
  * type:  protocol defect => editorial
  * severity:  - => Active WG Document
  * milestone:  => ietf80

Comment:

 According to discussion on the mailing list, editorial work is needed to
 split up the description into manageable chunks.
 (Possibly also add more of the rationale expressed on the list.)

-- 
---------------------------------+------------------------------------------
 Reporter:  likepeng@…           |       Owner:  hartke@…      
     Type:  editorial            |      Status:  new           
 Priority:  minor                |   Milestone:  ietf80        
Component:  observe              |     Version:                
 Severity:  Active WG Document   |    Keywords:                
---------------------------------+------------------------------------------

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