Subject: [core] message correlation on CoAP

From: "R.Vinob chander" <[email-masked]>
Date: Fri, 8 Jan 2016 09:28:03 +0530

Hi All,

  sec. 4.4 of RFC 7252 specifies

  The same Message ID MUST NOT be reused (in communicating with the
   same endpoint) within the EXCHANGE_LIFETIME

  I think the sentence is incorrect and should b,

  The same Message ID MUST NOT be reused (in communicating with the
   same endpoint) *beyond* the EXCHANGE_LIFETIME/NON_LIFETIME

Regards,
-- 
R. Vinob chander, B.E., M.E., (Ph.D)
Assistant Professor, Department of IT
SSN College of Engineering,
Old Mahabalipuram Road
Kalavakkam - 603 110
Tamil Nadu, India
www.ssn.edu.in

Phone: +9144-27469700 , +91 44 27474844/45/46
Extn: 370
Mob: +91-9566101580

-- 
::DISCLAIMER:: 

---------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of SSN Institutions (SSN) or its
affiliates. Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without the
prior written consent of authorized representative of SSN is strictly
prohibited. If you have received this email in error please delete it and
notify the sender immediately.
---------------------------------------------------------------------
Header of this mail should have a valid DKIM signature for the domain ssn.edu.in <http://www.ssn.edu.in/>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 8 Jan 2016 10:15:51 +0000

I think it is correct as written - the same ID must not be used within
EXCHANGE_LIFETIME. You can add NON_LIFETIME as well. The message ID
certainly can be reused beyond those lifetimes as the occurrence of the
message ID for acknowledgement or duplication detection is no longer
expected.

Robert

On 8 January 2016 at 03:58, R.Vinob chander <[email-masked]>
wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: "R.Vinob chander" <[email-masked]>
Date: Fri, 8 Jan 2016 21:06:57 +0530

thank u... u r right.....but the a receiver may get multiple copies of
the same message if the ACK is lost in transit..(sec. 4.5). So in such
cases the same message ID is used within the EXCHANGE_LIFETIME.

Hence i think probably the sentence should be  "The same Message ID
MUST NOT be reused (in communicating with the same endpoint) within
the first timeout for CON and MAX_LATENCY for NON"

4.4.  Message Correlation

4.5.  Message Deduplication

   A recipient might receive the same Confirmable message (as indicated
   by the Message ID and source endpoint) multiple times within the
   EXCHANGE_LIFETIME

4.8.2. 		

NON_LIFETIME is the time from sending a Non-confirmable message to
   the time its Message ID can be safely reused.  *If multiple
   transmission of a NON message is not used, its value is
   MAX_LATENCY, or 100 seconds*.  However, *a CoAP sender might send a
   NON message multiple times*, in particular for multicast
   applications.  While the period of reuse is not bounded by the
   specification, an expectation of reliable detection of duplication
   at the receiver is on the timescales of MAX_TRANSMIT_SPAN.
   Therefore, for this purpose, it is safer to use the value:

      MAX_TRANSMIT_SPAN + MAX_LATENCY

please clarify..

-- 
::DISCLAIMER::

---

From: Robert Cragie <[email-masked]>
Date: Fri, 8 Jan 2016 16:16:59 +0000

Hi Vinod,

Comments inline, bracketed by <RCC></RCC>

Robert

On 8 January 2016 at 15:36, R.Vinob chander <[email-masked]>
wrote:

> thank u... u r right.....but the a receiver may get multiple copies of the same message if the ACK is lost in transit..(sec. 4.5). So in such cases the same message ID is used within the EXCHANGE_LIFETIME.
>
> <RCC>Not really - retransmitting a CON message due to lost ACK does not
constitute reusing the same Message ID as it is essentially the same
message retransmitted. The emphasis is on *re*using; using the same message
ID again in the retransmission is not *re*using. So I think the original
text is OK.</RCC>

> Hence i think probably the sentence should be  "The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the first timeout for CON and MAX_LATENCY for NON"  						
>
> 4.4.  Message Correlation
>
> <RCC>The same applies for NON; retransmitting a NON (for example, for
robustness in the case of multicast) does not constitute reusing of the
message ID as it is essentially the same message retransmitted.</RCC>

> please clarify..			
>
> <RCC>I hope the above clarifies things</RCC>

>
> On Fri, Jan 8, 2016 at 3:45 PM, Robert Cragie <[email-masked]
> > wrote:
>