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

From: "core issue tracker" <[email-masked]>
Date: Tue, 15 May 2012 14:35:33 -0000

#201: Clarify use of retransmission window for duplicate detection

Comment (by cabo@…):

 Also:
 Angelo P. Castellani notes (msg02875a):

 Section 4.1 tells:

 The same Message ID MUST NOT be re-used (per Message ID variable) within
 the potential retransmission window, calculated as RESPONSE_TIMEOUT *
 RESPONSE_RANDOM_FACTOR * (2 `^` MAX_RETRANSMIT - 1) plus the expected
 maximum round trip time.
 Given that these parameters are not mandated by the standard, does the
 spec assume that will be available some way to synchronize those
 parameters across different implementations to correctly avoid reusing a
 MID in the retransmission window?

 Also:
 Cullen Jennings notes (msg03071):

 I don't understand when a MID can be reused.

 It seems to me that that once a MID is used, it can't be re-used for some
 significant amount of time.

 Also:
 Esko Dijk notes (msg03057b):

 Section 4.1

 The same Message ID MUST NOT be re-used (per Message ID variable)
 There seems to be a requirement here on the MID variable(s) of an
 implementation instead of requirements on MID (re)use in messages. (Any
 reason for this?)

-- 
-----------------------------+-------------------------------------
 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:2>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 15 May 2012 14:47:04 -0000

Comment (by cabo@…):

 Also:
 Michael Scharf notes (msg03280a):

 Section 4.1.

 The same Message ID MUST NOT be re-used (per Message ID variable) within
 the potential retransmission window, calculated as RESPONSE_TIMEOUT *
 RESPONSE_RANDOM_FACTOR * (2 `^` MAX_RETRANSMIT - 1) plus the expected
 maximum round trip time.
 At first sight, the RTT is not mentioned elsewhere in the document. Is my
 understanding correct that core does not measure the RTT? If so, it is not
 clear to me how a sender would know the "expected maxium round trip time".

 Also, note that if the intention is to ensure uniqueness of messages, the
 Maximum Segment Lifetime (MSL) matters. RFC 793 (arbitrarily) sets it to 2
 minutes for TCP.

 -> No, we don't assume that an end-point keeps per-peer RTT estimates.
 The MSL would need to be set in a somewhat arbitrary fashion similar to
 the way TCP does this.

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

---

From: "core issue tracker" <[email-masked]>
Date: Sat, 26 May 2012 12:35:55 -0000

Comment (by cabo@…):

 Some initial text for fixing this ticket is in section 7 (Protocol
 Constants and Time Constants) of http://tools.ietf.org/html/draft-bormann-
 coap-misc-17 -- once we have agreed on the terminology (do we need
 additional ones?), the calculations, and the assumed values, we can start
 editing this into core-coap.

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

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 28 May 2012 10:24:49 +0200

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?

Best,
Angelo

On Sat, May 26, 2012 at 2:35 PM, core issue tracker
<[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core