Opened 10 years ago

Closed 10 years ago

#201 closed editorial (fixed)

Clarify use of retransmission window for duplicate detection

Reported by: cabo@… Owned by: cabo@…
Priority: minor Milestone: post-WGLC-1
Component: coap Version: coap-09
Severity: In WG Last Call Keywords:
Cc:

Description

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?

Change History (9)

comment:1 Changed 10 years ago by cabo@…

Angelo Castellani notes:

What about NON messages? How much time the recipient MUST be prepared
to receive the same non-confirmable message? (to eliminate duplication
caused by the network)

Indeed, duplicate detection is not only for confirmable messages.

So #201 needs to talk about CON and NON.
The main point of #201 is that we clarify the text to use the term "retransmission window" as much as possible.

For NON, there is no retransmission, so the window could be smaller than for confirmable messages.
However, for most implementations, it will be easier to simply have a single timeout value for both cases.
This just needs to be large enough, and "retransmission window" will do it for NON, too.

comment:2 Changed 10 years ago 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?)

comment:3 Changed 10 years ago 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.

comment:4 Changed 10 years ago 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.

comment:5 Changed 10 years ago 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?

comment:6 Changed 10 years ago by zach@…

  • Owner changed from draft-ietf-core-coap@… to cabo@…

comment:7 Changed 10 years ago by cabo@…

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

comment:8 Changed 10 years ago by hartke@…

  • Milestone set to post-WGLC-1
  • Version set to coap-09

comment:9 Changed 10 years ago by cabo@…

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

Fixed in [838]:

fix #201

Note: See TracTickets for help on using tickets.