Subject: Re: [core] #201: Clarify use of retransmission window for duplicate detection

From: "core issue tracker" <[email-masked]>
Date: Mon, 04 Jun 2012 13:44:20 -0000

#201: Clarify use of retransmission window for duplicate detection

Comment (by angelo@…):

 from msg03376:

 Question 1)

 MAX_RETRANSMIT_WAIT has been defined assuming that after the last
 retransmission, the endpoint should wait

 RESPONSE_TIMEOUT * (2 ** MAX_RETRANSMIT) * RESPONSE_RANDOM_FACTOR

 seconds before giving up definitely receiving a response. Is it right?

 ###########################################################################
 ###########################################################################
 ###########################################################################

 Question 1.1)

 What is the rationale behind having a lot of definitions such as
 MAX_LATENCY, MAX_RTT, PROCESSING_DELAY, EXCHANGE_LIFETIME?

 More clearly, why do we define later that the effective time that a
 node should wait to satisfy the defined worst case network conditions
 should be:

 PROCESSING_DELAY + (2 * MAX_LATENCY)

 This conflicts with MAX_RETRANSMIT_WAIT... Or am I missing something?

 ###########################################################################
 ###########################################################################
 ###########################################################################

 Question 2)

 It is not clear to me why do we define a simplified EXCHANGE_LIFETIME to:

 (RESPONSE_TIMEOUT * (2 ** MAX_RETRANSMIT) * RESPONSE_RANDOM_FACTOR) +
 (2 * MAX_LATENCY)

 Shouldn't be

 PROCESSING_DELAY + (2 * MAX_LATENCY)

 when we use NON messages, and

 MAX_RETRANSMIT_SPAN + PROCESSING_DELAY + (2 * MAX_LATENCY)

 when we use CON messages?

-- 
-----------------------------+-------------------------------------
 Reporter:  cabo@…           |       Owner:  draft-ietf-core-coap@…
     Type:  editorial        |      Status:  new
 Priority:  minor            |   Milestone:
Component:  coap             |     Version:
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+-------------------------------------

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

---

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

Having a look at the  DTLS 1.2 RFC, I saw that they use TCP's 120 seconds as constant for reusing the epoch value.
Would it make sense to harmonize our "ID lifetime value" with this, as DTLS is expected to be used a lot together with CoAP?

Having thought more about this ID reuse issue, I also think Carsten's calculation is a good estimation for an upper bound:

	MAX_RETRANSMIT_SPAN + PROCESSING_DELAY + (2 * MAX_LATENCY)	(= 248s)

But IMHO, MAX_RETRANSMIT_SPAN and MAX_LATENCY are correlated and having different values for CONs, NONs, and also the observe clock makes this more complicated than it is.

Thus, my vote is for 120 seconds to simplify and harmonize with DTLS.
A client gives up after 93s (due to 4 retransmission and an exponential timeout). So we do not expect any message with the used ID after this timespan. Additional 27s make a good, quite conservative safety margin for "strange effects" in a multi-hop low-power network.

Best regards
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Jun 2012 13:18:35 +0200

On Jun 8, 2012, at 11:16, Kovatsch Matthias wrote:

> DTLS 1.2 RFC, I saw that they use TCP's 120 seconds

RFC 6347, 4.1 (p. 9):
...MAY choose to retain
   keying material from previous epochs for up to the default MSL
   specified for TCP [TCP] to allow for packet reordering

This is the maximum expected reordering, i.e. something that would apply to our NON usage, not a CON situation -- the value equivalent to our MAX_LATENCY.  It also is about the time when state is discarded the lack of which simply causes a protocol operation to detectably fail, as opposed to the protocol potentially acting confused.

So I think this is good input for our choice of MAX_LATENCY (another argument for choosing 120 s instead of the 100 s I proposed).  It is not helping us to decide when MID-related state can be discarded for CON exchanges.  I still think that the text in coap-misc-17 here is correct.  We just need to add a discussion of NON state lifetime, and that will be closer to the DTLS discussion.

Grüße, Carsten

PS.: The language (that is, in so many words, circuitously trying to avoid spelling out the "120 s" that it simply means) suggests to me that choosing this value was a struggle when DTLS was defined, too.

Note also the text:

   In addition, for at least twice the default MSL defined for [TCP],
   when in the FINISHED state, the node that transmits the last flight
   (the server in an ordinary handshake or the client in a resumed
   handshake) MUST respond to a retransmit of the peer's last flight

Rescorla & Modadugu          Standards Track                   [Page 23]
RFC 6347                          DTLS                      January 2012

   with a retransmit of the last flight.  This avoids deadlock
   conditions if the last flight gets lost.

which is closer to our CON considerations.  So this MUST here would be 2*MAX_LATENCY, but without an allowance for MAX_TRANSMIT_SPAN.

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 13:48:23 -0000

#choose ticket.new
  #when True
 A recipient MUST be prepared to receive the same confirmable message
    (as indicated by the Message ID and additional address information of
    the corresponding end-point as described in Section 4.3) multiple
    times, for example, when its acknowledgement went missing or didn't
    reach the original sender before the first timeout.  The recipient

 Question 2: Should be specified that "the recipient MUST be prepared to
 receive the same confirmable message *within the potential retransmission
 window*" as well?
  #end
  #otherwise
    #if changes_body
Changes (by zach@…):

 * owner:  draft-ietf-core-coap@… => cabo@…

    #end
    #if changes_descr
      #if not changes_body and not change.comment and change.author
Description changed by zach@…:
      #end

--
    #end
    #if change.comment

Comment:

    #end
  #end
#end

-- 
-----------------------------+---------------------
 Reporter:  cabo@…           |       Owner:  cabo@…
     Type:  editorial        |      Status:  new
 Priority:  minor            |   Milestone:
Component:  coap             |     Version:
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+---------------------

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

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 25 Jun 2012 17:08:56 -0000

Comment (by cabo@…):

 Text in section 6 of coap-misc-18, to be moved over to core-coap.

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

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 25 Jun 2012 20:10:55 -0000

Changes (by hartke@…):

 * version:   => coap-09
 * milestone:   => post-WGLC-1

-- 
-----------------------------+--------------------------
 Reporter:  cabo@…           |       Owner:  cabo@…
     Type:  editorial        |      Status:  new
 Priority:  minor            |   Milestone:  post-WGLC-1
Component:  coap             |     Version:  coap-09
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+--------------------------

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