Subject: [core] #276: Use of EXCHANGE_LIFETIME in reordering detection

From: "core issue tracker" <[email-masked]>
Date: Sat, 02 Feb 2013 01:13:55 -0000

#276: Use of EXCHANGE_LIFETIME in reordering detection

 The mechanism for reordering detection in observe-07 depends on
 EXCHANGE_LIFETIME and that both client and server use the same value for
 this variable. If the client and the server do not use the same value for
 EXCHANGE_LIFETIME, things break (see offlist13j).

 EXCHANGE_LIFETIME is calculated (among other variables) from ACK_TIMEOUT.
 However, if an implementation dynamically adjusts the RTO (= ACK_TIMEOUT)
 based on RTT samples (see draft-bormann-core-cocoa-00), then the value of
 EXCHANGE_LIFETIME changes dynamically as well.

 So, with RTO Estimation, it is basically impossible for the client and the
 server to keep their EXCHANGE_LIFETIME values in sync.

 Solution: Define a new variable in -observe to be used instead of
 EXCHANGE_LIFETIME for reordering detection. Its value MUST be no less than
 the maximum EXCHANGE_LIFETIME that can result from dynamically adjusting
 ACK_TIMEOUT. Client and server MUST use the same value. Give a fixed
 default value based on default CoAP transmission parameters. If in the
 future endpoints are negotiating CoAP transmission parameters, this value
 needs to be negotiated as well.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  [email-masked]         |  [email-masked]
     Type:  protocol     |     Status:  new
  defect                 |  Milestone:  post-WGLC-1
 Priority:  minor        |    Version:  observe-07
Component:  observe      |   Keywords:
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

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

---

From: "core issue tracker" <[email-masked]>
Date: Sat, 02 Feb 2013 18:18:27 -0000

Comment (by [email-masked]):

 Actually, the value does not necessarily need to be no less than the
 maximum EXCHANGE_LIFETIME, since the sequence number must be updated each
 time a notification is retransmitted. The value must be no less than the
 maximum time a datagram is expected to take from the start of its
 transmission to the completion of its reception (MAX_LATENCY).

Component:  observe      |  Resolution:
 Keywords:               |

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

---

From: "core issue tracker" <[email-masked]>
Date: Sat, 02 Feb 2013 23:47:18 -0000

Converse argument: if the value was no less than the maximum
 EXCHANGE_LIFETIME, then the sequence number would not need to be updated
 each time a notification is retransmitted.

 This is already the case if the sequence number is based on a per-resource
 variable that is incremented each time the resource changes, and the
 resource did not undergo a change before the notification is
 retransmitted. So the argument is relevant only in the case where the
 sequence number is based on the timestamp from a local clock.

 However, observe-07 currently requires that "a server uses a number of
 retransmit attempts (MAX_RETRANSMIT) such that removing a client from the
 list of observers before Max-Age ends is avoided." Since there is no limit
 on MAX_RETRANSMIT, there is no maximum EXCHANGE_LIFETIME.

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

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 04 Feb 2013 21:42:19 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 observe-08 now uses a fixed constant of 128 seconds. This is a nice, round
 number that is slightly larger than CoAP's MAX_RETRANSMIT (100 seconds)
 and TCP's MSL (120 seconds).

 * If a client receives a notification, and then nothing for 128 seconds,
 and then a second notification, then that second notification cannot
 originate from before the first notification. So, after 128 seconds, the
 client does not need to compare the sequence numbers to determine that the
 second notification is newer than the first one.

 * If a client receives a notification and then a second notification
 within 128 seconds, then it needs to compare the sequence numbers to
 determine if the second notification is newer than the first one. The
 largest delta between two sequence numbers that it is meaningful in 24-bit
 space is `2^(24-1)-1`, so the sequence numbers must not increase faster
 than by `2^24` in less than 256 seconds.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]         |  [email-masked]
     Type:  protocol     |      Status:  closed
  defect                 |   Milestone:  post-WGLC-1
 Priority:  minor        |     Version:  observe-07
Component:  observe      |  Resolution:  fixed
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

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