Opened 10 years ago

Closed 10 years ago

#276 closed protocol defect (fixed)

Use of EXCHANGE_LIFETIME in reordering detection

Reported by: hartke@… Owned by: draft-ietf-core-observe@…
Priority: minor Milestone: post-WGLC-1
Component: observe Version: observe-07
Severity: In WG Last Call Keywords:
Cc:

Description

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.

Change History (3)

comment:1 Changed 10 years ago by hartke@…

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

comment:2 Changed 10 years ago by hartke@…

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.

comment:3 Changed 10 years ago by hartke@…

  • Resolution set to fixed
  • Status changed from new to closed

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.
Note: See TracTickets for help on using tickets.